过去几年，架构领域最火的方向之一莫过于微服务。实践微服务的好处显而易见，比如其本身所具备的可扩展性、易维护性、独立自治、故障和资源隔离等诸多特性，可以大大提高产品研发效率。同时，基于微服务架构设计风格，研发人员可以构建原生对“云”具备超高友好度的系统，让产品的持续集成与发布更为便捷，也为后续拥抱“云原生”打下了坚实的基础。

但是，在计算机的世界中，没有哪项技术可以大一统地解决所有问题，微服务同样如此。被认为是十大软件架构师之一的Chris Richardson曾一针见血地指出:“微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间的通讯机制。此外，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”

在组织的业务系统向微服务架构演变的过程中，存在很多问题需要解决，比如进行微服务的时间点；按照组织架构合理拆分和容量规划的方法；应对大规模瞬时流量的冲击以及比较理想的实施路径等。在ArchSummit 全球架构师峰会（深圳站）2019 大会期间，InfoQ 有幸采访到乐信架构总监康彬，探讨他从 0 到 1 进行团队搭建并主导推动多轮系统架构演变的亲身经验。

从 0 到 1 的架构演变历程

最开始的两年基本每天都在救火，因为会遇到各种新问题，可能是因为基础技术产品缺失，也可能是已有基础技术产品存在缺陷，或者业务研发同学使用不当等。总之，每天都在解决各种问题，被各种问题驱动向前不断迭代。

乐信是一家互联网金融科技服务商，集团旗下主要业务包括品质分期购物平台分期乐商城、网络借贷信息中介服务平台桔子理财以及金融资产开放平台鼎盛资产等。回顾整个架构搭建过程，康彬表示，乐信的技术架构演变主线非常清晰，但在当时团队人员只知道大致方向，并没有具体规划到每一步，更多是由问题驱动逐步演化至今。

一直以来，康彬始终认为不管是单体应用架构还是微服务架构，都只是一种技术体系，没有好坏之分，只有是否合适。乐信的系统架构经历了 PHP 单体应用架构、PHP 服务化、Java 服务化、混合云、单元化和同城双活几个阶段。虽然每个阶段解决的具体问题不一样，但这些问题本质都上都是业务持续爆发性增长带来的技术新挑战。

创业初期，验证业务的可行性非常重要，PHP 的便捷性是当时乐信合适的选择。康彬透露，直到现在，乐信内部依旧有系统在使用 PHP 技术栈，主要是一些对高可用性要求不高或变化较快的系统，比如 OA 系统。

随后，乐信对系统进行了微服务改造，如上图，最底层是由运维团队提供的各种资源，包括计算资源、存储资源、网络资源等。中间件层主要分为微服务框架、消息中间件以及 Job 调度系统三部分。其中，微服务框架解决的是同步调用问题，消息中间件解决的是异步调用问题，调度系统解决的是后台计算逻辑，比如风控处理等问题，其上承接两大平台——核心交易平台和风控审核平台，共同提供了获客、授信、下单以及还款等基础中台能力，这些基础中台能力支撑着上层各种前台业务的快速发展。

但是，如果遇到大促，系统还是存在一些问题需要解决，比如机器准备周期长、紧急情况无法应对；大促后机器闲置率高，资源浪费巨大。因此，乐信开始探索混合云架构，将流量大户置于公有云之上，保证机器资源按需申请；接入层按 URL 调度流量；服务层 Set 化的路由策略；数据层读请求上云，写请求回自建 IDC。

即便这套架构足以满足当下需求，但混合云从物理层面来看是两个机房，逻辑上还是一个集群，因为乐信内部的云机房和本地机房共用一套注册中心。随着流量越来越大，集群规模越来越大，单集群模式如何应对？如果发生机房级的灾难，单机房怎么办?

基于上述担忧，乐信研发团队又开始探索同城双活的解决方案，在接入层建立起用户维度的流量调度能力；统一集团 Job 调度平台、分离 service 和 job；跨机房的统一配置中心；mq 具备单元化路由及容灾能力；统一开放网关建设，划清业务板块边界；全链路系统诊断能力建设完成后，乐信的混合云 & 同城双活方案基本搭建完毕。

从最开始的 PHP 服务化 1.0 阶段解决单体应用架构的问题，到后来的 Java 服务化 2.0 阶段解决 PHP 技术栈继续演进遇到的困境，再到解决大促痛点的混合云，以及解决跨机房容灾的单元化和同城双活方案。在这个过程中，乐信内部逐渐衍生出发布系统、监控告警系统、全链路诊断系统等 DevOps 相关系统，消息中间件、配置中心、定时任务调度中心、分布式文件存储系统等微服务架构必备的相关基础技术产品，以及针对微服务架构的开发测试解决方案稳态环境及配套的开发测试流程及工具。最终，这些组成了现在乐信的底层基础技术平台。

如今，乐信完成了接入层、服务层、中间件层的单元化和同城双活能力，数据层虽然也有对应的跨机房容灾，但本质上数据层还是一个中心，在同一个城市或者两个距离很近的城市，比如广州和深圳，一些对跨机房延迟不太敏感的业务还可以满足。未来，如果想做到相距千里之外的异地多活，数据单元化是一个绕不开的问题。另一方面，乐信的混合云虽然已经可以应付各种大促，但过程中还是需要投入较多人力做压测、容量评估、扩容、缩容等重复性工作，未来有望借助全链路诊断体系和自动化性能评估体系逐步自动化完成，做到一键弹性扩缩容或自动化扩缩容。

微服务实践心得

如开篇所言，微服务的好处已经被总结过很多次，比如分而治之降低系统复杂度和耦合度，各服务独立开发部署利于团队闭环、也有利于并行开发提高生产力，这些好处背后隐藏的是一系列复杂变化，这时就需要一系列支持体系来解决这些问题，包括开发、测试、部署、线上运维、线上故障定位及业务架构分析等。

在过往四年的微服务改造过程中，乐信曾经有一段时间爆发过开发测试环境问题。康彬透露，当时，开发人员在环境上花费的时间超过写代码的时间，测试人员在环境上消耗的时间超过测试时间，运维人员更加痛苦，有多少并行需求就需要维护多少套独立开发测试环境，这些就是为了获取微服务的好处而付出的代价。

因此，康彬认为是否采用微服务要根据实际的业务情况决定，考虑原有的单体应用架构体系是否确实无法支撑业务持续爆发性增长。经过各方面综合分析后，如果企业认为必须走微服务这条道路，那就需要考虑如下四个因素：

1、架构团队的技术储备是否有能力在代码层面对微服务所依赖的各种框架、中间件进行把控；
2、基于微服务架构的各种流程规范、包括底层技术产品的使用规范、开发测试流程规范、发布规范以及对应的检测机制等是否已经准备好；
3、相应的 DevOps 体系是否开始规划，包括 CMDB 系统、发布系统、监控告警系统、全链路诊断系统等；
4、业务研发团队是否准备好，包括组织架构转变、研发流程的转变、开发方法及习惯的转变、所有这些都需要长期培训及技术支持来确保有序进行。

当研发人员习惯微服务架构体系下的研发方式后，开发一个服务就变得非常简单。所以，大部分人会选择开发独立的新服务来满足各种业务需求，带来的后果就是服务和接口数目持续增长，各业务板块之间的边界越来越模糊，复杂性和成本远远超出预期。乐信及时意识到这个问题，开始推进业务架构整改，包括梳理并下线历史遗留的无效系统，分析单次用户 Http 请求对应的后台 RPC 调用层次和总数的合理性，解除业务板块间不合理的耦合，以此推动关联性较大的小服务的合并，沉淀各业务版本都需要的公共服务，逐步形成资源层、中间件层、核心交易和风控两大平台，以此支撑上面的具体业务，走的是大中台、小前台的路线，这也是康彬目前比较推荐的方式。

至于微服务容量规划，康彬坦言这确实是一个痛点。乐信对这个问题的解决方式也在持续进行中。目前，康彬比较推荐的方式是单体和整体综合治理的方式，单体就是针对单个服务、单个接口性能测试常态化，以此来掌握各个单体的性能趋势，线下压测是个常见的方法，如果能在线上实现自动化性能压测，那么测试数据更接近真实情况，对容量预估的帮助也更大。整体可以分为单个 URL 下各关联服务的整体性能压测、以及多个 URL 组成的单元整体对外性能压测，要实现这个需要各种中间件支持，类似阿里的全链路压测方案，这个实现成本比较大，在业务规模增长到一定程度后再进行更加合适。

结束语

每家企业都有不同的业务状态，实施路径还是要根据具体情况来定，康彬在采访最后表示，推进过程可能需要随时根据情况变化进行调整，没有大一统的实施路径，但技术能力储备、规范流程建设、配套 DevOps 体系搭建、组织架构以及研发方法的持续优化等依旧是需要关注的重点。