丰隽玮：非常荣幸就我们在微服务架构上的实践和大家做交流，主要内容是这几个部分，一是我们目前对微服务这套体系的理解，二是我们在微服务架构设计上有哪些思考，三是我们在微服务落地方面的实践，四是我们基于微服务的实践看到的一些问题，重点关注治理方面。
其实大型的金融企业都是经过三个系统架构发展的阶段，一是分散的阶段，也就是各地的机构会自建他的系统，这种系统大多是单体架构的应用，非常简单直接，主机时代典型的架构。
到了2000年左右，大家都在做总部大集中的事情，这时候是一种垂直的架构，很多很多的系统以竖井烟囱式来形成一组对业务的支撑能力。这个时候各系统之间的交互，我们就引入了SOA的架构方式，这种粗粒度、中心化的面向服务架构。
后来就步入了互联网架构的时代，也就是云阶段。这个时候基础设施已经做到了云化，系统慢慢的向分布式架构、容器化、微服务、云原生去演化，这时候强调原子服务，自治独立部署、平台治理，主要是这三个架构演化的过程。
技术趋势一直在关注和强调共享和重用，它们相辅相成推动了技术的发展，并且都是采用同样的思路，以大拆小的思路，把底层的技术难题往应用层去推，让应用层解决这些问题。主要目前关注的四块领域：
一是微服务这个领域，强调服务重用共享，流程重组、服务编排以及怎么去敏捷开发、交付和部署。
二是云计算这边的基础设施资源共享、动态分配、提高利用率，横向扩展的高可用的架构支持。
三是人工智能，包括大数据、数据的共享分析以及人工智能相关的应用场景。
四是平台化的概念，我们把技术和业务做了一个分离，独立成一个平台来提升重用共享。对于技术的标准和一些落地的通用的技术服务，通过平台化的方式提供。
SOA和微服务到底是什么样的关系？微服务不是凭空出来的，我们认为它还是SOA概念的一个演进，但微服务强调的是组件的拆分和独立变化。对于SOA它主要解决集成技术标准和服务重用。微服务架构是在SOA的基础上，解决实现SOA服务的载体自身怎么去独立快速变化的这么一个问题。我们通俗的理解，微服务架构就是把一个大系统按照业务的功能拆成职责单一的小系统或者叫它组件，再利用一些简单的方式使很多的小系统互相协作起来，形成我们想要的大系统，就是一个拆和合的过程。
我们认为微服务不是一个银弹，既有优点也有挑战。优点是简单灵活、高内聚松耦合，由不同的团队独立开发运营，可以使用不同的语言和工具、轻量化的通讯交互、去中心化。在真正落地的层面上来看它有哪些优点？我们认为就是快和敏捷。对于我们开发过程来讲，有利于敏捷开发，服务因为拆分细了，可以有一些小团队独立开发维护，效率提高了，沟通成本也低了，响应也快了，研发周期也短了，更好适应业务的变化。
二是便于横向扩展，可以独立分布式的部署，需要性能扩展的时候可以做一些有针对性的措施。
三是提高复用，可以按照业务领域来组织微服务，能提高组件的复用能力。
四是服务的独立部署，服务间通过API接口依赖，把技术选型做到较强的无关性，有利于技术的快速升级。
微服务整体的架构规划和架构设计层面对我们提出很多的挑战，另外是跨服务的全流程测试更复杂了，全链路的运维工作也更加复杂了。还有一个最经典的问题，对于金融企业来讲，事务一致性的问题是非常严重的，因为涉及到金融的交易，强一致性到最终一致性的转变如何适应。
我们做微服务化的动力是什么？是两个方面对我们的要求。
一是我们的需求交付的时效要求越来越高了，因为整个应用的重心从原来的E端、B端过渡到C端，对C端用户的需求，要求IT如何去快速的迭代，敏捷的交付，提出一个很大的挑战。
二是我们的系统压力越来越大，我们也在做一些去小型机的工作，基本上X86已经全覆盖了，原来这些巨无霸的应用再也没有一个非常强大的集中式硬件体系去支撑它了，它的CPU、IO越来越高，如何去解决它？这是给我们带来的两个问题。
我们要做微服务化其实还有一些先决条件，首先对人员团队层面来讲，我要去做微服务化，需要敏捷交付的团队，基于契约化去做团队的协作，需要敏捷的平台支撑的运维团队，这是需要有一个持续改进的团队组织来形成。
二是对技术储备来讲，我们的计算资源如何快速分配。我们原来是物理机过渡到虚拟机，再过渡到容器化，可以让全新的服务器设备在几个小时乃至几分钟内就交付出来。关于基础运维和监控层面如何快速检测、定位有问题，这是一个必要必备的条件。另外是关于快速部署、自动化流水线这个层面，怎么从开发到测试到预发、生产，有一个全流程的流水线去支撑它，这是我们在技术层面做了一些储备。
下面讲一下我们在架构设计层面的沉淀。这是微服务架构的一个实例，我们会有很多面向业务域的一些微服务，通过API的方式提供出来，然后再通过面向不同业务域的API网关向外提供服务，不管APP也好或者微信也好。底层会有一个微服务的治理平台，统一的实现注册、发现，熔断，链路跟踪等一些功能。
应用架构目前分了五层，最上层是终端用户的设备层，进来之后有一个企业级的负载均衡器来提供流量的接入。再下面是网关层，是按照不同的业务域提供的，将一些请求反向路由到微服务，负责技术接入，这一层跟业务逻辑无关的，无状态部署。再下一层是BFF层，面向不同业务域聚合服务，裁剪加工后暴露给前端请求。再下面一层是领域服务层，这一层提供支持业务的核心领域服务，比如一些客户服务、保单服务、支付服务等等。再下面是数据访问层，提供对数据存储、数据访问的支持。。
另外我们建了两个平台，一个是微服务的登记平台，主要是针对微服务和API生命周期管理的，还有一个微服务运行时的管理平台，包括服务的注册、发现、鉴权、熔断、降级、链路跟踪这些公共的服务。
再讲一下我们如何考量这个微服务拆分的，有两个维度。一是基于领域模型和业务因素去考量，二是基于技术和团队因素考虑。首先是单一职能的原则，第二是业务差异性，这两个结合起来考量，领域和业务因素。
这是一个例子，保险行业里承保系统是非常关键的系统，我们基于DDD的领域驱动设计方式，对保单管理这一块进行一个拆分。就拆分成了报价、投保、核保、续保等等一些环节。在投保环节中就发现了业务的差异，包括产品线不同，客户群体不同，或者渠道不同的话，相应的投保流程服务也都不同。那么再继续拆，就拆成通用的投保、意外险的投保、个人车险的投保等等，面向各种不同场景的微服务。
下面是基于团队和技术层面的考量。首先是运营时的隔离，会根据一些特定功能单独拆分出来作为一个微服务。举个例子，有一些文件上传的API，它的特征是响应时间长，对IO的依赖也比较多，线程池也需要特殊配置，这种情况会把这些微服务做一些隔离。第四个原则是非常经典的康威定律，到底团队影响拆分还是拆分影响团队，是需要去平衡的。比如我们一些存量的系统，因为去拆分服务了而进行了团队的拆分，可能会最后影响到团队的稳定性和归属感。反之，如果团队负责多种业务，也没有明显职责区分的话，这时候要考虑团队的拆分，明确拆分后的团队职责。
总结一下，对于正在运行的系统，如果我们要做微服务化的话，如何拆分和拆分成多大的粒度，本身是不能太过理论化和理想化的，还是需要深入到团队内部和业务场景里去，了解人和代码。既不是拆迁队的方式，简单粗暴，也不是修缮的方式，应该是合理的搭积木的这种方式。因为团队不同、项目不同，实践也是不同的，也没有很多参考，所以找到自己团队合适的方法就可以了。
再讲一下我们在微服务实施方面的一些实践，首先是技术选型。对于我们技术选型主要考量的是四个维度，一是本身的技术和功能这个维度，二是项目的运作模式，三是提供者的背景，四是生态环境。简要来讲，是不是这种技术大量在线上已经投入生产了，二是你的团队是不是能cover住这种技术，基于这些点我们做一个技术的选型。
这里列了一些主流的分布式框架，我们在考量的时候，其实也是基于上面几个原则做了一些考量，同时我们也在关注Service Mesh，但其目前还不具备生产投产的基础。基于这几个评判维度我们做了一些微服务的技术选型，我们目前整个团队还是以Java技术栈为主，这里面有一些是基于开源项目的使用和修改，也会有一些是通过自研提供的能力。
这是我们在微服务实施过程中的阶段，我们叫1.0阶段，其实是一个项目级的阶段，大量的C端应用起来的时候，我们把核心系统里的服务能力重新互联网化，做了一些微服务的拆分，拆完以后基于我们自研的API网关，提供出API服务出来，在前端对C端用户提供业务能力。
这种模式在过程中也发现一些问题，首先并没有真正做好服务的复用，其它项目要用到这些服务的时候，并没有提供这个能力出来。二是缺少必备的一些服务治理的能力。后来就到了企业级的2.0阶段，这个阶段我们是把微服务按应用域归并，在应用域内，一系列的服务通过域内的网关提供能力输出。域和域之间还有一些域间网关，提供跨域的服务能力输出。同时还通过登记平台和管理平台提供一些必备的治理能力。
刚才讲了治理，我们面对治理有哪些需求呢？我们总结一下，两个维度。一是服务的监控维度，二是服务的管控维度。服务的监控维度主要是哪些？服务的基础信息、质量、容量、依赖、分布、统计、元数据、查询、报表以及APM监控等等，对服务的全生命周期全链路跟踪的维度去考量的。
二是服务的管控能力，对服务的上下线、服务的文档、升级、路由、限流降级、授权等。基于这个治理的需求，我们从技术层面也做了一些思考。因为整个服务治理来讲是一个很大的体系，时间有限我也不展开讲了。就从技术层面来讲，首先对于开发环境，我们提供了整个微服务开发需要依赖的SDK、规范、项目模版、MockServer等。另外对微服务全生命周期管理提供一个登记平台，包括业务域的管理、业务系统、应用、微服务到API以及相应的版本上下线整个生命周期的管理，覆盖了服务的静态、动态和管理属性。
通过管理平台解决微服务运行时全景的监控和管控，包括运行时详情的查看，路由的规则、流量的策略，包括配置管理、监控统计，API Store，注册中心、配置中心的一些设置，这是一些截图。这是系统的拓扑图，这是调用查询的跟踪，断路器，链路分析等。
对于开发环境标准化这一块来讲，一个企业如果要做微服务的话，首先对于技术的标准化这一块，如果真正做到规范化和标准化，对于微服务化可能会带来很大的一些便利。我们也做了很多标准化的工作，包括提供了一些规范和脚手脚，应用的开发规范、接口的规范、治理的规范，包括一整套微服务项目的模板。另外提供了一些微服务开发应用依赖的JAR包，包括日志记录、访问控制，微服务容器相关功能，都封装在SDK里面。另外对于测试来讲，提供服务Mock的功能，基于契约的方式去测试。
另一块就是统一运行平台，有注册中心、配置中心、API网关，应用监控中心、断路器监控中心、认证中心、日志中心，还有对微服务运行期支持多版本的概念，还有服务容器，将一些必要的能力进行SDK的封装。
这些就是我今天分享给大家的一些在微服务应用实施中的经验，谢谢大家。
热门专题
