搜索 | 会员  
微服务架构的核心要点和实现原理
来源: 收集   作者:李艳鹏  日期:2017-8-22  类别:架构设计  主题:架构设计  编辑:满是深爱
传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。

    微服务架构中职能团队的划分

 

    传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证。如果其中一个模块化组件需要升级、更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段需要沟通业务回归等事宜,甚至上线都需要跨团队沟通应用的上线顺序。可见在传统的整体架构下,后期的维护成本很高,出现事故的风险很大。

 

    根据康威定律,团队的交流机制应该与架构设计机制相对应。因此,在微服务架构下,职能团队的划分方法是我们首先要考虑的一个核心要素。

 

    微服务时代的团队沟通方式如图1-9所示。

 

微服务架构的核心要点和实现原理 

 

图1-9

 

    微服务架构按照业务的功能进行划分,每个单一的业务功能叫作一个服务,每个服务对应一个独立的职能团队,团队里包含用户交互UI设计师、后台服务开发人员、DBA、运营和运维人员。

 

    在传统的整体架构中,软件是有生命周期的,经历需求分析、开发和测试,然后被交付给运维团队,这时开发团队将会解散,这是对软件的一个“放手”。而在微服务架构中,提倡运维人员也是服务项目团队的一员,倡导谁开发、谁维护,实施终生维护制度。

 

    在业务服务的内部实现需要升级或者变更时,团队内的各角色成员进行沟通即可,而不需要进行跨团队沟通,这大大提高了沟通效率。只有服务之间的接口需要变更时才需要跨部门沟通,如果前期在服务之间的交互上定义了良好的接口,则接口变更的概率并不大,即使接口模式有变更,也可以通过一定的设计模式和规范来解决,可参考1.3.3节。

 

    微服务的去中心化治理

 

    笔者曾经在一个互联网平台上工作,平台的决策者倡导建设API网关,所有外部服务和内部服务都由统一的API网关进行管理。在项目初期,中心化的API网关统一了所有API的入口,这看起来很规范,但从技术角度来看限制了API的多样化。随着业务的发展,API网关开始暴露问题,每个用户请求经过机房时只要有服务之间的交互,则都会从API网关进行路由,服务上量以后,由于内部服务之间的交互都会叠加在API网关的调用上,所以在很大程度上放大了API网关的调用TPS,API网关很快就遇到了性能瓶颈。

 

    这个案例是典型的微服务的反模式,微服务倡导去中心化的治理,不推荐每个微服务都使用相同的标准和技术来开发和使用服务。在微服务架构下可以使用C++开发一个服务,来对接Java开发的另外一个服务,对于异构系统之间的交互标准,通常可以使用工具来补偿。开发者可以开发共用的工具,并分享给异构系统的开发者使用,来解决异构系统不一致的问题,例如:Thrift远程调用框架使用中间语言(IDL)来定义接口,中间语言是独立于任何语言的,并提供了工具来生成中间语言,以及在中间语言与具体语言之间的代码转换。

 

    微服务架构倡导去中心化的服务管理和治理,尽量不设置中心化的管理服务,最差也需要在中心化的管理服务宕机时有替代方案和设计。在笔者工作的支付平台服务化建设中,第1层SOA服务化采用Dubbo框架进行定制化,如果Dubbo服务化出现了大面积的崩溃,则服务化体系会切换到点对点的hessian远程调用,这被称为服务化降级,降级后点对点的hessian远程调用时没有中心化节点,整体上符合微服务的原理。

 

    微服务的交互模式

 

    本节介绍微服务之间交互的通用设计模式,这些设计模式对微服务之间的交互定义契约,服务的生产者和调用者都需要遵守这些契约,才能保证微服务不出问题。

 

    1. 读者容错模式

 

    读者容错模式(Tolerant Reader)指微服务化中服务提供者和消费者之间如何对接口的改变进行容错。从字面上来讲,消费者需要对提供者提供的功能进行兼容性设计,尤其对服务提供者返回的内容进行兼容,或者解决在服务提供者改变接口或者数据的格式的情况下,如何让服务消费者正常运行。

 

    任何一个产品在设计时都无法预见将来可能增加的所有需求,服务的开发者通常通过迭代及时地增加新功能,或者让服务提供的API自然地演进。不过,服务提供者对外提供的接口的数据格式的改变、增加和删除,都会导致服务的消费者不能正常工作。

 

    因此,在服务消费者处理服务提供者返回的消息的过程中,需要对服务返回的消息进行过滤,只提取自己需要的内容,对多余或者未知的内容采取抛弃的策略,而不是硬生生地抛错处理。

 

    在实现过程中不推荐使用严格的校验策略,而是推荐使用宽松的校验策略,即使服务消费者拿到的消息报文发生了改变,程序也只需尽最大努力提取需要的数据,同时忽略不可识别的数据。只有在服务消费者完全不能识别接收到的消息,或者无法通过识别的信息继续处理流程时,才能抛出异常。

 

    服务的消费者的容错模式忽略了新的消息项、可选的消息项、未知的数据值及服务消费者不需要的数据项。

 

    笔者当前在某个支付公司工作,公司里几乎每个业务都需要使用枚举类型,在微服务平台下,笔者在研发流程规范中定义了一条枚举值使用规范:

 

    在服务接口的定义中,参数可以使用枚举值,在返回值的DTO中禁止使用枚举值。

 

    这条规范就是读者容错模式在实践中的一个实例,之所以在参数中允许使用枚举值,是因为如果服务的提供者升级了接口,增加了枚举值,若服务的消费者并没有感知,则服务的消费者得知新的枚举值就可以传递新的枚举值了;但是如果接口的返回DTO中使用了枚举值,并且因为某种原因增加了枚举值,则服务消费者在反序列化枚举时就会报错,因此在返回值中我们应该使用字符串等互相认可的类型,来做到双方的互相兼容,并实现读者容错模式。

 

    2. 消费者驱动契约模式

 

    消费者驱动契约模式用来定义服务化中服务之间交互接口改变的最佳规则。

 

    服务契约分为:提供者契约、消费者契约及消费者驱动的契约,它从期望与约束的角度描述了服务提供者与服务消费者之间的联动关系。

 

  • 提供者契约:是我们最常用的一种服务契约,顾名思义,提供者契约是以提供者为中心的,提供者提供了什么功能和消息格式,各消费者都会无条件地遵守这些约定,不论消费者实际需要多少功能,消费者接受了提供者契约时,都会根据服务提供者的规则来使用服务。


  • 消费者契约:是对某个消费者的需求进行更为精确的描述,在一次具体的服务交互场景下,代表消费者需要提供者提供功能中的哪部分数据。消费者契约可以被用来标识现有的提供者契约,也可以用来发现一个尚未明确的提供者契约。


  • 消费者驱动的契约:代表服务提供者向其所有当前消费者承诺遵守的约束。一旦各消费者把自己的具体期望告知提供者,则提供者无论在什么时间和场景下,都不应该打破契约。

 

    在现实的服务交互设计中,上面这三种契约是同时存在的,笔者所在的支付平台里,交易系统在完成一笔支付后,需要到账务系统为商户入账,在这个过程中,服务契约表现如下。

 

  • 生产者契约:账务系统提供Dubbo服务化接口,参数为商户账户ID、入账订单号和入账金额。


  • 消费者契约:账务系统返回DTO,包含商户账户ID、入账订单号、入账金额、入账时间、账务流水号、入账状态等,而交易系统只需使用其中的入账订单号和入账状态。


  • 消费者驱动的契约:为了保证资金安全,交易系统作为入账的发起者向账务提出要求,需要账务做幂等和滤重处理,对重复的入账请求进行拦截;账务系统在接受这个契约后,即使将来有任何改变,也不能打破这个限制,否则就会造成资金的损失,这在金融系统中是最严重的问题。

 

    服务之间的交互需要使用的三种服务契约如图1-10所示。

 

微服务架构的核心要点和实现原理 

 

图1-10

 

    从图1-10可以看到,服务提供者契约是服务提供者单方面定下的规则,而一个消费者契约会成为提供者契约的一部分,多个服务消费者可以对服务提供者提出约束,服务提供者需要在将来遵守服务消费者提出的契约,这就是消费者驱动的契约。