「这是我参与2022首次更文挑战的第41天，活动详情查看：2022首次更文挑战」

微服务架构模式

微服务架构正在业界迅速普及,她是单个应用的代替品,特点是面向服务. 微服务架构还在发展中,这次只是提及关键的概念.

模式描述

不论是何种拓扑何种实现,有几个概念是通用的.

独立部署单元,第一个概念. 微服务的每个组件都是一个独立的部署单元, 简化交付,高可伸缩性,高级别应用,组件松耦合,都是其特点.

服务组件是最核心的概念.组件可以大到一个程序, 可以小到一个模块,颗粒度很自由. 服务组件可以包含一个或多个模块,模块可以是单个功能函数, 也可以是大型业务程序中的一部分.

服务组件的颗粒度是微服务设计架构的挑战问题, 近期的说法是尽量小且独立.

分布式架构是另一个概念.意味着服务组件的松耦合, 意味着可扩展性和某些部署特性.

微服务架构是从问题演变而来,不是先有解决方案后有问题. 微服务架构来至两方面:单应用使用分层架构模式; 分布式程序使用面向服务的架构模式.

单应用到微服务是cd(持续交付)的促进, 单应用普遍是紧凑的,单个部署单元, 变更/测试/部署麻烦且困难,"月级部署"就是说的这种窘境. 这些因素会导致脆弱的程序,每次部署一些新东西都可能中断. 微服务通过将程序分为多个部署单元来解决这个问题, 额外的好处是开发/测试/部署独立.

面向服务的架构 service-oriented architecture pattern(SOA), soa提供了强大的抽象/异构连接/服务编排/并承诺业务目标和it能力一致, 除了这些,还有复杂/昂贵/无处不在/难以理解和实现, 多大多数程序来说,体量过大了. 微服务针对问题,简化了很多,具体是提出了服务的概念, 消除了服务编排需求,简化了服务组件的连接和访问.

服务拓扑

微服务的实现方式有几十种,有3种拓扑是最常见也是最受欢迎的:

• 基于rest api的拓扑
• 基于rest 应用的拓扑
• 集中式消息拓扑

rest api拓扑,非常适合网站站点,尤其是站点需要暴露的服务是较小, 且自包含时,在微服务架构模式中,将组件都称为微服务.

在rest api拓扑下,微服务(就是组件)的颗粒度都非常小, 一个微服务包含1-2个模块(模块会执行指定的业务功能, 且模块和剩下的服务是独立的).细颗粒度非常适合基于rest. 要访问微服务,需要通过基于web的api层.

rest api拓扑和rest 程序拓扑的区别在于通过何种方式接收客户端请求: 一个是通过简单的api层;一个是通过传统的基于web/胖客户端的业务程序, 英文是user-interface layer,也就是用户交互层.

用户交互层是作为一个独立的web程序去部署的,用户交互层会访问微服务, 方式也是基于rest的.

rest api拓扑和rest 程序拓扑中的微服务(组件)也是有区别的: api拓扑中的微服务趋向于细颗粒度,一个微服务表示的是一个动作; rest 程序拓扑的微服务趋向于粗颗粒度,更多的是代表业务程序中的一个小部分. rest 程序拓扑适合中小型程序,且程序的复杂度不高的那种.

最后一种拓扑是集中式消息拓扑.相比前两种拓扑,集中式消息拓扑更小, 没有使用rest来访问微服务,而是更加轻量级的集中式消息协调者. 不能将集中式消息拓扑和"面向服务的架构"/"阉割版soa"混淆.

集中式消息拓扑的客户端请求先到用户交互层,再到轻量级的消息协调者, 最后到微服务.

集中式消息拓扑内的消息协调者并不执行编排/转换/复杂路由, 她只做传输,客户端的请求到远端微服务的传输.

大型程序,或程序对"用户交互层到微服务的传输"需要更复杂的控制时, 多使用集中式消息拓扑.相比基于rest,集中式消息拓扑的优势如下: 消息队列机制/异步消息的传递和监控/错误处理/更好的负载均衡和可伸缩性. 缺点也有的,单点故障和架构瓶颈问题均涉及消息协调者, 这点可通过将消息协调者部署为集群来解决.(按系统功能将协调者拆为多个).

避免依赖和服务编排

微服务架构模式第一个挑战就是组件(微服务)颗粒度的划分. 颗粒度太粗不会体现出微服务架构的优势(部署/可伸缩/测试性/松耦合). 颗粒度太细就需要服务编排,服务编排的出现意味微服务架构 正在向重型面向服务的架构转变,慢慢soa的特征就出现了: 复杂/混乱/昂贵/无处不在.

如果在用户交互层或web api层需要用到服务编排,说明颗粒度小了; 如果在一个请求中,需要处理服务间的交互,说明颗粒度大了, 或者说明从业务功能的角度看,没有划分正确.

服务间的交互,会导致耦合性,通过共享数据库可解耦. eg:处理订单的微服务可以去数据库获取用户信息,而不是去掉用户服务.

共享数据库是推荐的,那么共享功能呢? dry: don't repeat yourself.微服务架构中,对于公用功能,推荐拷贝, 共享不适合微服务架构.为了独立部署,少量的冗余是可接受的.

如果最终还是发现无法避免服务编排,说明架构模式没有选择正确. 分布式导致在跨微服务的情况下,很难维护事务. 如果使用某种事务补偿框架来回滚事务,那就让简单优雅的微服务架构变得 非常复杂了.

注意事项

微服务架构模式解决了单体应用和面向服务架构的很多问题. 程序被拆分成小片,单独部署,更强的健壮性,更高的可伸缩性, 对持续交付的天然支持.

微服务架构模式解决的另一个领域是部署. 组件独立表示隔离,隔离意味易部署,意味整体灵活性. 单体程序的更新部署意味热部署,微服务则可在部署周期内可实时部署.

微服务架构是分布式架构,分布式架构的坑一个也没落下: 约定的创建和维护;远端系统可用性;远程身份认证和授权.

架构模式分析

具体可查看附录

整体灵活性

高,组件独立,变更不会影响其他组件.松耦合就是灵活性高.

部署难度

低,和微服务的颗粒度有关.

可测试性

高,拆分的更小,更易于测试.

性能

低,微服务架构是分布式架构,特征中没有高性能.

可伸缩性

高,每个组件都可单独部署,单独扩展.

开发难度

低,组件独立,功能隔离,每个组件的功能和范围都很小, 开发难度低.单个组件的修改不会影响其他组件.