微服务架构 浅谈

什么是微服务?

其实最近两年微服务这个概念挺火的,那其实究竟什么是微服务呢?

微服务其实是一种架构风格、一种约定。就和我们开发中使用的设计模式是一个道理。
每个微服务仅关注于完成一件任务
每个微服务独立部署,互不干预
一个应用由一个或多个微服务组成

把我们上一文中的单体架构,拆分成微服务的结构,那么应该是如下图:

对小型商城应用的拆分

这里我们将每个功能拆分为一个单独的服务,有自己的web容器,然后通过gateway连结起来,对外提供服务。用户只和Gateway打交道,有点像是反向代理的感觉。

但这里的拆分并不一定非得变为这样,你可以拆得更细,或者是更粗,视你业务情况而定,不要脱离业务谈架构

这些服务之间如何通信?

我们将一个商城应用拆分为如上图所示后。当用户购买一件商品时,要涉及到支付、修改购物车信息、修改商品库存、发送短信通知 等多个服务。
当我们将整个单体架构拆为这样的微服务时,他们之间如何通信和协作呢?

通信方式分为同步、异步两类

同步:

P2P      P2P方式中,服务之间直接相互调用,每个服务都对外开放自己的API并调用其他服务的接口

Gateway      Gateway方式中,服务之间相互调用也通过API网关

P2P优点:少一次网络IO,P2P缺点:无法做流量控制、无法记录具体调用情况。Gateway调用方式的优缺点正好与之相反

异步:

消息中间件      一般用于下游服务执行时间不可控,或与调用者接下来逻辑无关联的情况

一般同步通信下我们使用 HTTP RESTful 方式,异步下我们使用消息中间件(如消息队列、发布/订阅等)

一般常用的消息格式为 JSON


如何划分你的团队/服务 规模

2P2W 原则:

2 Pizza – 负责一个服务的团队,不要让两个Pizza不够分,也就意味着最好不要超过6个人,如果你服务粒度很小,那么2-3个人也不是不行

2 Week – 一个团队对其所负责的服务,如果要进行重构,时间不要超过2周,也就意味着太复杂或是工程太浩大的服务,需要考虑再次进行拆分


微服务的优点&挑战

优点

简单
        一个服务只关注一个功能

扩容灵活
        哪个服务需要扩容,就给哪个服务单独做扩容

技术栈灵活
        各团队可以自行选择最佳的技术栈来进行开发,例如Go支撑高性能服务,PHP支持普通业务

持续集成友好
        允许我们在频繁发布不同服务的同时,保持系统其他服务的可用性

挑战

需要技术和流程积累,例如CI/CD流程、最好还需要可靠的云团队负责 Docker+K8S

运维成本        需要构建/测试/部署/运行 数十个甚至更多的服务。不同的服务有不同的技术栈,运维人员难以全部精通,开发人员才是运维该服务的专家

人才稀缺        具有较强的DevOPS能力的人才稀缺。

分布式系统带来的问题        分布式事务、网络延迟/波动 等。

难以全面测试        需要自动化流程,不论是自动化测试还是自动集成,一般常用的质量保证手段是上线后通过监控发现生产环境的异常,进而快速回滚或采取行动

划重点

每个微服务是一个单体架构

每个微服务专注于一个功能

数据需要去中心化,每个微服务只能访问自身的数据库

一套微服务组合起来,对外提供一个完整的服务