转载

ORA宣传月第二弹—— ORA之微服务框架

金融行业需要的韧性微服务体系

随着微服务架构的越来越普及，开发一个微服务也越来越简单。

当前出现了很多的服务框架（例如Dubbo、SpringCloud等），微服务开发人员只要专注于实现自己的业务逻辑，通过简单的配置或添加注解就可以基于RPC的服务发布和调用。

一切看起来那么简单，那么美好。然而，距离成为满足金融行业生产环境高可用性、具有很强的鲁棒性的IT系统，还存在很大的差距，让我们看几个真实的案例。

蓝翔技校，高可用杀手

继2015年成功挖断支付宝光缆之后，蓝翔技校再次扮演了系统高可用杀手的角色： 2019年6月2日凌晨，AWS位于北京数据中心的光缆被挖断。托管在AWS的VIPKID无法提供服务，为我们辛苦的中国小朋友献上儿童节贺礼：终于可以休息休息，不用再上课。

ORA宣传月第二弹—— ORA之微服务框架

少配一个参数，引发的API网关宕机血案

该案例来自于某互联网公司。

2018年的1024。本该是一个和平，宁静的周三，本该是程序猿自己的节日。然而还没有开始上班，噩梦就已经开始。

早上八点半到公司，突然业务群反馈用户使用APP请求一直在转圈。

半小时过去了，定位到问题—— API网关服务挂了。网关服务挂了……网关服务……挂了……

jstack一查。 250个线程在跑。 100个线程挂起。链路日志一查，一大半的请求超过10分钟。。 10分钟？

ORA宣传月第二弹—— ORA之微服务框架

最后定位到某个服务调用疯狂超时，导致其他服务一直等待线程资源。

有一个后端服务因为调用第三方导致完全处于宕机状态，所有gw过去的请求都会超时。
由于这个服务的请求又特别多，导致GW分给这个服务的连接池耗尽无法获取到连接资源，导致资源请求线程一直积累在GW
GW的对应这个服务的线程数一直在增加，导致别的服务也无法正常工作。

最后的处理办法，为对外调用设置一个合理的超时时间，避免无限期的等待。

其实，在微服务体系下，如果实现引入了服务熔断机制，就会更加优雅和有效避免在外调失败时，对自己的系统造成不良影响，避免级联失败。

以上案例证明了金融级IT系统应该具有良好的韧性，通俗讲就是具有鲁棒性，而非一碰就倒的花瓶、需要精心维护。而设计一个韧性的金融级微服务体系，通常遵循以下两方面的设计原则：

1 面向故障设计

充分考虑分布式微服务架构下会存在的各类故障，针对故障进行针对性的设计；并进行故障测试，检验系统是否具备应对故障的能力。这样，当故障真正发生时，才能从容应对，避免造成严重影响。

面向恢复设计

充分考虑系统中应用节点出现宕机等不可用情况时，能够及时发现并自动恢复。这里讲的恢复既包括集群中应用节点宕机之后的重新启动，也包括对宕机应用处理中的业务的自动恢复。

从具体技术细节上，我们认为金融级微服务体系应该至少具备以下几方面的能力：

★

高级别的冗余性

支持应用多活部署与灾备，能够支撑应用基于LDC（逻辑分区单元）的部署

良好的扩展性

具备处理应对高并发请求的能力

避免级联故障

能够应对分布式环境下服务相互调用故障，具体措施包括合理的重试、超时机制、幂等操作、服务降级、熔断等；

完整的运维支撑体系

包括持续集成与发布，服务跟踪、监控等能力。能够在复杂的分布式环境下，帮助运维轻松进行日常管理和应对各类突发事项。

ORA宣传月第二弹—— ORA之微服务框架

ORA高可用微服务体系

经过多年的研究，结合业界目前主流的微服务和韧性系统理论，分布式技术团队对微服务体系重新进行定义，打造满足金融行业要求的ORA（欧拉）微服务体系。

愿景

让业务的归业务，技术的归技术。

业务应用开发人员只需要专注于业务功能实现，分布式环境下复杂的非功能特性由 ORA微服务体系完成。

服务模型

作为一个专业的程序猿，从上大学的时候我们就知道这么一个公式：

程序=数据结构+算法

ORA服务模型的定义也是非常简洁的一个公式：

服务=参数+方法

一个微服务本质是一个完成单一业务职责的服务。对于服务使用者来说，只关注服务的定义（参数与方法），而不会关心服务的细节：

参数：包括出参、入参。与集中式应用不同，分布式架构体系下，服务的入参还为服务路由提供了数据基础（在进行单元化部署时，由于数据进行了分库分表部署，需要对每个服务请求进行路由分发）；
方法：包括功能方法、非功能方法。功能方法实现了业务功能；非功能方法是为了确保分布式环境下服务具备自愈性、可恢复性和一致性而必须实现的方法（例如：为了支持分布式事务需要提供的冲正方法）。

ORA服务模型图如下，服务由参数与方法构成。特别需要说明的是，服务的入参和非功能方法，为分布式架构下服务的自愈性、可恢复性和一致性提供了支撑，具体非功能特性包括幂等性、故障恢复、分布式事务和服务跟踪等。

ORA宣传月第二弹—— ORA之微服务框架

ORA微服务体系

ORA微服务体系以“服务模型”为中心，通过“服务调用链”机制，将ORA分布式框架提供的各个分布式组件进行串接，让每一个微服务天然具备了应对复杂分布式环境的能力。

ORA宣传月第二弹—— ORA之微服务框架

在整个体系中，分布式组件都是相互独立、与服务模型与调用链松耦合的，应用开发者可以按照自己的需要自由选择；每个组件具备单一职责，为微服务的非功能特性提供支持：

序号	分布式组件	功能
1	服务框架	提供对应用透明的RPC服务框架
2	服务治理	集成行内标准的服务治理体系，提供访问控制、限流等处理，为微服务保驾护航
3	全局路由	提供服务网关（API Gateway）、基于服务数据的路由分发功能
4	配置中心	提供分布式环境下应用配置的统一管理；将应用代码与配置分离，实现一份代码多份部署
5	统一交易流水	提供交易幂等性控制；交易状态查询和统一冲正处理
6	分布式跟踪	提供分布式环境下微服务调用跟踪能力，可以精确到每一次对外调用（服务间、中间件、数据库）