文 / 中国人民银行清算总中心 葛洪慧
随着新的业务场景和交易需求的不断涌现，单体架构难以满足快速实现新业务发展需要。近年来，基于云计算技术的分布式系统得到广泛应用，其特点是在架构层面具备更优秀的横向扩展和弹性伸缩能力。基于云计算的微服务技术架构，因其适应现代业务发展的技术特征，在分布式系统中得到广泛的应用，其可靠性与稳定性均得到验证。
技术特征
ThoughtWorks首席科学家总结亚马逊等互联网架构实践，首次提出了微服务架构的概念。著名架构师Adrian Cockcroft把微服务架构定义为面向服务的架构，它们由松耦合和具有边界上下文的元素组成。这里的边界上下文可理解为可以用通用IDL接口定义语言定义服务接口。因此，服务、服务接口和接口间通信构成微服务的体系架构。
从微服务概念可以看出，微服务有如下技术特征。特征1：微服务具有高内聚松耦合特征。Robert C.Martin的单一原则“把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来”很好地说明了高内聚性。特征2：微服务相对较小，解决性能问题更细粒度，对于密集型CPU需求或内存需求可分开部署，分别拓展。拆分现有业务时，微服务大小适中。微服务太小，服务间通信频繁，也增加运行维护复杂度。微服务太大，失去微服务的意义。特征3：微服务的自治性或独立性。微服务可独立部署、独立扩展、独立修改。其升级维护不影响其他服务的运行。微服务可多个实例运行，提高系统整体可靠性，单个微服务故障，可以进行隔离不影响整体可用性。特征4：技术异构性。在保证与其他服务接口不变情况下，可在某些服务中尝试新技术。特征5：可组合性或可重用性。基于相同软件产品线的业务系统，可通过组合重用相同的服务组件，构成新的业务系统。特征6：具备灵活应对需求变化能力，可实现持续交付和持续部署，更好地实现开发运维一体化。
关键技术
微服务的分布式事务管理是一项关键技术。在计算机科学理论中CAP定理指出，分布式系统的一致性、可用性和分区容错性只能满足三项中的两项。X/Open分布式事务处理模型（X/Open XA）是分布式事务管理的事实标准，XA使用两阶段提交来确保事务中的所有参与者都提交或回滚，能够保证分布式事务的ACID属性。微服务分布式事务管理的TCC模式是基于XA协议的应用层实现，能保证分布式事务的ACID属性。不过，目前有些TCC分布式事务管理机制对应用的侵入性较强，应用编程复杂，且部分系统软件产品不支持XA协议。那么，将插删改同一数据库的业务逻辑聚合在一个微服务中，避免出现分布式事务的一致性问题，也是一种实现方式。未来，TCC有望减少应用对事务的管理，也会有更多的软件支持XA协议。
微服务服务间通信是另一项关键技术。微服务间通信方式有同步通信和异步通信两种机制。同步通信是基于请求应答协议的远程调用，代表性有REST、gRPC等。由于网络是不可靠的，服务端可能会返回一个错误信息。因此，服务间采用同步通信方式，微服务框架应有服务治理中心和注册中心，实现局部故障处理和服务发现。异步通信方式一般是基于消息代理或消息，消息通道传递信息。消息代理应有控制消息并发、消息顺序和重复消息的管理机制。
微服务通信支持的编码/解码方式有文本和二进制方式。文本方式可读性好，编码后数据结构体大，传输效率低。Protocal Buffer是一种二进制编码方式，每个字段有编号和类型代码，消息接收方可跳过不可识别的字段提取所需字段，因此具有向前兼容特性，同时具有语言和平台无关性、更好的传输效率。在对性能要求较高的设计中应考虑选择基于二进制的编码方式。
系统结构
如图所示，以华为微服务引擎CSE构建为例。基于微服务架构设计的应用系统结构通常可以划分为应用软件层SaaS、公共服务层bPaaS、平台层PaaS、数据层DaaS和基础设施层IaaS。
图 总体架构图
CSE是Apache ServiceComb开源微服务架构的商业微服务应用管理平台，包含微服务服务注册、配置和治理中心。CSE集成在华为Fusionstage PasS平台，提供RPC协议，使用ProtoBuf做序列化编码，支持Docker容器运行。
使用领域驱动的设计思路，按照高内聚松耦合特征，将应用程序划分为不同的微服务，位于SaaS层。公共服务位于bPasS层。
PasS平台层通常集成多种引擎或组件，比如微服务引擎、云容器引擎、分布式消息中间件、分布式缓存中间件、分布式事务管理组件等。微服务引擎负责服务发现、服务配置、服务路由，多通信访问、服务容错、熔断、服务限流降级、服务隔离等服务治理功能。云容器引擎负责应用管理、应用编排、容器存储和IaaS适配。分布式缓存则提高热点数据访问加速，非关键数据或过程数据在缓存读写，降低数据库访问负荷。分布式消息中间件则可以通过消息队列，实现应用解耦和与第三方的互通或集成。华为Fusionstage PasS平台，提供应用软件开发流水和应用运维监控功能。
IaaS层通常基于OpenStack技术构成计算资源池、存储资源池。
DaaS层由数据库组成。
注意：上述系统结构中，如果IaaS层不使用分布式存储，也可以简化为使用Kubernets直接管理裸金属服务器，使得整体系统结构简单便于维护。
应用设计
在应用设计中，特别是对原有多个业务系统基于微服务的架构进行改造时，可以考虑在统一架构的基础上，把一些共用的业务逻辑，比如数据检查、加解密等提取出来，作为不同的单独的微服务，而归属于原业务系统自身的业务逻辑作为一个或几个微服务。这种公共微服务产品化的抽取，促进了不同业务系统的产品整合，减少了不同业务系统的应用程序冗余。
具有公共业务逻辑属性的微服务产品，因微服务技术本身支持独立性和技术异构性，这些产品可以独立演进，尝试不同的技术，以提升业务系统适应新技术能力。这类产品可由专门的团队研发和演进。
通常业务系统中并不是所有的业务逻辑都需要考虑分布式事务的一致性，特别是在数据库性能不受影响的情况下，可以将业务逻辑设计在一个微服务中，利用数据库的事务一致性来保证。所以，在选择微服务接口设计时，可以精细化的选择接口调用方式，对于确实需要同步调用以保证分布式事务一致性的选用同步调用接口设计，对于大部分业务逻辑可以采用异步调用接口设计，提高系统整体性能。
应用设计中，还应注意将具有强关联业务逻辑设计为一个微服务，减少微服务与微服务之间频繁的接口调用，微服务间调用接口清晰，微服务调用微服务的逻辑链不宜过长。
测 试
微服务产品的版本管理是基于语义化版本控制规范，和通常单体产品版本管理基于功能兼容性有所区别，更多的是基于接口修改是否兼容进行控制。因此在产品制版和测试时，需注意和单体一次制版一次部署整体测试不同，可以进行微服务产品的单独制版，单独部署，并注意测试其接口兼容性。
部 署
微服务实例可运行在容器中。根据应用功能、被调用的频率和需要的计算资源的大小，为微服务分配实例数量，提高系统整体性能。将同一微服务的不同实例运行在不同机柜上，提升系统整体可用性。比如可以将计算资源按机柜分成不同的高可用计算资源集群，每个集群划分为一定数量的节点，节点标签用微服务名命名，在分配标签时，遵循“具有相同节点标签的节点属于不同高可用计算资源集群”原则，提升可用性。
在金融业务系统面临转型发展关键时期，研究分布式微服务技术，利用国产商用或开源软件和硬件构建业务系统，提升系统整体风险防控能力是十分必要的。
（栏目编辑：韩维蜜）
热门跟贴