金融互联网行业微服务架构必须要考虑的几件事 | ArchSummit

嘉宾 | 韩冬振

编辑 | 李忠良

在什么情况下，公司应该使用微服务？使用微服务之后，可能会有什么样的提升？又有哪些挑战以及哪些闭坑经验？本次采访，我们邀请到了众安金融高级架构师韩冬振，请他分享了众安金融微服务落地经验，希望为你带来思考。

InfoQ：老师可否先和大家聊聊你现在在做什么，在你目前负责的工作中，哪一部分最有挑战性？

韩冬振：目前主要负责系统建设产品化和团队的搭建管理工作。要说哪一部分具有挑战性，那先要从业务说起，随着众安金融信保业务近年来的稳步增长，积累了大量的优质用户，如何利用普惠金融的优势为用户提供更加丰富和优质服务成为考虑的方向，为此我们提出包括商业化和生活服务在内金融 2.0 综合金融方向发展方向。

基于这样的背景，加上我们一直坚持科技赋能业务发展的原则，技术部门在架构上要对架构做出有前瞻性的迅速调整，之前我们的架构采用的中台模式，能通过中台将松散的高内聚微服务合理编排为信保领域内不同业务模式提供便捷的支撑，但是要中台对服务的组合来快速实现新的业务模式的支持，像需要敏捷迭代的商业化和生活服务就显得力不从心，需要通过对原微服务的深度的升级改造，涉及到大量的回归测试工作。

如何既要保证系统稳定性使原有业务不受影响，同时又能快速完成系统升级支撑新业务成为核心技术部门面临巨大的挑战。这时我们就提出敏捷中台的模式，其特点是尽最大可能复用现有中台服务功能，同时为了保持新业务的敏捷性，新建业务垂直型的服务，保证业务的快速上线试跑，根据试跑的结果，在业务取得一定市场机会时将新业务沉淀抽象，形成新的内聚性服务链，加入中台，或者在业务改变方向时，可实现低成本的快速抛离，也不会影响原有中台的运行。

这样的敏捷中台架构模式既保证了中台架构的连贯性一致性，同时也能很好赋能突破创新业务，使得中台更具生命力。

InfoQ：众安金融什么时候开始进行的微服务架构设计？很多人说，其实不用微服务架构，或者说不轻易使用微服务，可否结合您的经历聊聊，为什么众安使用微服务？

韩冬振：众安金融是 17 年开始采用微服务架构体系的，主要有两方面的原因：一方面有需要，微服务架能够解决支持众安金融业务，我们的存量业务模式更新迭代快同时要不断试跑新业务模式，之前应用采用的服务化架构，服务的颗粒度过大，逻辑复杂，每次升级迭代需要较长的开发周期，勉强能够支持影响业务的开展。微服务架构就以其服务职责相对单一，高内聚的特点，在可测试性、可维护性、可部署性方面有着天然的优势，可以更方便的持续集成持续交付。

另一方面能落地，众安金融有相对敏捷技术团队和比较完善的技术积累支持，包括相对完善服务治理体系、开发测试发布流水线工具、敏捷需求开发测试工具和稳定工具团队，以及云原生基础设施体系，这都为微服务架构的落地实施提供坚实的底座。

微服务架构也不是银弹，不能解决所有的架构问题，一定要克服一种观念，架构可以一劳永逸，一蹴而就解决所有问题。很多人不轻易使用微服务，不外乎以下几个原因：

1. 大型单体服务划分好领域进而拆分成合适粒度微服务需要有丰富的领域知识储备；
2. 拆分后大量的微服务，要聚合起来，服务的稳定性、可靠性、性能都面临挑战；
3. 微服务和原系统的兼容也是实践中的一大障碍；

另外，不容忽视的一点架构的转变还会带来组织架构的调整，这也可能是阻力之一。虽然存在以上问题，微服务体系架构方法论和实践对以上问题也均有应对方案。关于是否使用微服务架构，个人觉得一个衡量的标准，微服务的优势是否能更好的支撑业务的开展。另外，实践上建议小步快走，逐步切换微服务架构，使得业务能够尝到采用微服务架构带来的甜头，成为微服务架构落地的驱动力。

InfoQ：通过微服务架构，众安金融达到了什么成效？开发效率是否有提升、开发成本是否有降低呢？

韩冬振：要说微服务架构带来的成效，最显著的是开发生产效率得到了质的提升。由于微服务本身的粒度相对比较小，再加上践行 CI\CD 流水线作业，使得业务需求版本上线保持质量的前提下时效非常灵活和快速，可以支持随时上线。

众安金融常态下前端系统团队保持一周上线一版本，业务调整试跑期甚至在一周内上线多个版本，核心体统团队也能日常两周一迭代，甚至一周一迭代，这样的节奏在金融行业是非常快的了。

另外，微服务的业务架构、技术架构也带来了组织架构的敏捷化，小而精的自治性开发团队组织形式，更加有利于知识的积累和沉淀，再加上采用持续交付模式，使得开发人员各位业务、技术、运维均得到成长和锻炼，使得整个开发上线流程更加流畅，更加有效率。

总之，微服务架构带来的不仅是框架、流程、组织甚至是认知上的变化，使得整个团队脱胎换骨，更加高效。

InfoQ：微服务架构演进过程中，您都碰到了哪些难题？众安在不同业务阶段采用不同的微服务架构模式，最根本的判依据有哪些？

韩冬振：微服务架构个系统的工程，其演进不仅是业务架构、技术架构的调整，还需要在组织架构、流程制度以及成本预算、时间约束等方方方面的情况做出调整和权衡。每一次的架构演进升级都会遇到各种各样的阻力，这里主要说下底层技术框架的切换遇到的难题：

1. 原来的框架还勉强能支持业务的开展，框架升级会挤占业务需求开发的时间，对于业务驱动的团队来说优先级相对不高；
2. 新框架的切换能带来效率的提升但可能会导致业务的不稳定，没人愿意第一个吃螃蟹；针对这个问题的最佳实践是找到共同的利益点，一方面架构升级给业务带来的是业务落地效率的提升，把架构的升级结合业务的需求同步进行，小步快走，早见效，提升业务的感知度；

另一方面技术上，提供完善的切换方案和支持，从边缘系统开始尝试切换，让技术运维人员看到方便，同时打消顾虑。

• 众安金融的架构演进历程基本就是按这个套路来的：
• Monoliths 模式 业务发展早期，合理利用 Monoliths 模式特点实现快速复制，支持业务的快速上线跑量；
• 分层结构微服务模式 简单业务业务跑量期，模式有了一定沉淀，抽象不同业务层，各层分而治之各司其职，提升运维和服务效率及稳定性；
• 中台化微服务模式 业务领域内业务模式创新期，通过对内聚集对外抽象形成服务，以搭积木的方式组合快速形成新的业务模式；
• 敏捷中台产品化模式 业务领域突破期，领域内成熟业务模式产品化对外输出赋能，领域外后敏捷中台试跑新领域新业务，快速占领市场；

众安金融做架构演进的最根本判断依据：技术要赋能业务。架构者需要时刻的关注业务发展的阶段，结合技术发展的脉络，果断有前瞻性的做出架构升级的决策。能够迅速支撑业务开展的架构就是合适的架构。至于采用什么样的技术，考虑是否匹配业务，合适最重要，小马拉大车，技术驮不起业务的开展。牛刀杀鸡造成资源浪费。

InfoQ：结合您的实践和观察，金融互联网行业的开发架构与其他传统金融行业或者互联网行业的架构设计上有哪些异同？

韩冬振：传统的金融行业，像银行、基金业务业模式相对比较稳定，系统架构指标上强调系统可靠性、可用性，安全性，再加上传统上使用 IOE，因此架构上倾向于集中式单体架构或者采用大颗粒度的分布式 SOA 架构。随着客户群里的多样化，零售金融的崛起，传统金融行业某些业务领域会受到些许冲击，在架构上也逐渐在考虑使用微服务架构边在边缘系统做试点。

互联网行业直面大量 c 端长尾用户，需求多样千人千面，更看重系统的系统性能、可扩展性、可伸缩性、可维护性，系统能够快速迭代演进，微服务的架构是我们当前的首选。金融互联网行业则是要兼具金融和互联网的属性，设计目标要求更高，对应的在架构设计上需要兼顾可扩展性、可伸缩性、可维护性、可用性、可靠性、安全性，更宜采用云原生微服务架构，微服务、容器化、持续集成、持续部署，一体化监控运营体系。

其实，不管是互联网金融行业、金融行业、还是传统行业，都需要保持对前沿技术的关注度，在一些边缘系统上尽在的采用新技术，了解新技术的优缺点，是否与本公司的实际情况契合，积累一些实战经验，做好技术的储备。但是要避免为了新技术而为了赶时髦采用新技术，不能为业务带来价值，就本末倒置了。

InfoQ：您认为金融行业微服务架构必须要考虑哪些事情？有什么避坑经验可以分享给大家吗？

韩冬振：金融行业在采用微服务之前需首先需谨慎考虑系统的现状，单个应用现在是否过度复杂难以扩展维护，代码冲突团队协同代价高开发速度缓慢；是否存在开发周期部署周期长等问题，若存在微服务架构就是备选项之一；

其次，架构的变更需要对应的组织架构的匹配变更，开发交付的流程需要升级改造， 稳定性机制是保障。最后，尽可能全面拥抱云原生，这将充分发挥微服务敏捷的价值。只有这样架构方向把握好，人员组织好，流程制定好，小步快走，将微服务逐步从边缘系统过渡到核心系统，实现最终的相对统一的微服务架构体系。

这方面的最佳实践是:

1. 领域建模，服务拆分。以 DDD 的方法论指导，金融行业尽管有专业的领域专家优势，但是大部分金融机构采用外包的开发模式，带来领域专家和技术人员脱离的问题，因此我们建议要有核心技术架构师做统一的归口和部署；
2. 对应的需要建立敏捷的开发模式和敏捷的开发团队；
3. 采用持续交付模式，devops 流水线会让交付模式更加顺滑；
4. 建立横向的稳定性虚拟团队，确保业务、系统的稳定性问题的管理；

落地过程中遇到三大坑点的问题：

1. 部分服务拆出了微服务，服务的使用方却没有足够的热情来使用，切换进度不理想。针对这种情况可采用的方式绞防腐层模式 + 绞杀者模式闭坑。新服务上加盖防腐层转换网关，旧瓶装新酒。老的应用不再升级，逐步绞杀老的应用，若要使用新功能使用新的微服务。
2. 稳定性保障，微服务架构设计之初其实已经考虑到数据不一致的问题，但是采用 saga 等分布式数据一致性保障机制有过重。效果也不尽入任意。这时宜采用柔性设计的磁策略，异常可补偿 + 准实时核对机制 + 闭环业务监控解决此问题。

最后，好的架构是演化出来的，没有一劳永逸的架构，在业务发展的不同时期，需要有合适于那个时期的架构体系，在运维过程中不断地反思、沉淀、打磨、进化，形成符合自己业务特色的的架构风格，这也是架构的魅力所在。

嘉宾介绍

韩冬振，核心平台技术部负责人。专注金融互联网架构，12 年金融互联网行业开发架构管理经验。目前负责支付清结算平台、会员中心、信贷核心平台等系统搭建和升级，同时兼顾金融中后台产品孵化输出。