从 到 实现支撑百亿级请求量的微服务架构演化.docxVIP

从 0 到 1 实现支撑百亿级恳求量的微服务架构演化 最开头的两年基本每天都在救火，由于会遇到各种新问题，可能是由于基础技术产品缺失，也可能是已有基础技术产品存在缺陷，或者业务研发同学使用不当等。总之，每天都在处理各种问题，被各种问题驱动向前不断迭代。 乐信是一家互联网金融科技服务商，集团旗下次要业务包括质量分期购物平台分期乐商城、网络借贷信息中介服务平台桔子理财以及金融资产开放平台鼎盛资产等。回顾整个架构搭建过程，康彬表示，乐信的技术架构演化主线格外清楚，但在当时团队人员只晓得大致方向，并没有具体规划到每一步，更多是由问题驱动逐渐演化至今。 一直以来，康彬一直认为不管是单体应用架构还是微服务架构，都只是一种技术体系，没有好坏之分，只要能否合适。乐信的系统架构经受了 PHP 单体应用架构、PHP 服务化、Java 服务化、混合云、单元化和同城双活几个阶段。虽然每个阶段处理的具体问题不一样，但这些问题本质都上都是业务持续迸发性增长带来的技术新挑战。 创业初期，验证业务的可行性情外重要，PHP 的便捷性是当时乐信合适的选择。康彬透露，直到现在，乐信内部照旧有系统在使用 PHP 技术栈，次要是一些对高可用性要求不高或变化较快的系统，比如 OA 系统。 随后，乐信对系统进行了微服务改造，如上图，最底层是由运维团队供应的各种资源，包括计算资源、存储资源、网络资源等。两头件层次要分为微服务框架、消息两头件以及 Job 调度系统三部分。其中，微服务框架处理的是同步调用问题，消息两头件处理的是异步调用问题，调度系统处理的是后台计算规律，比如风控处理等问题，其上承接两大平台——核心买卖平台和风控审核平台，共同供应了获客、授信、下单以及还款等基础大陆与台湾力量，这些基础大陆与台湾力量支撑着上层各种前台业务的快速进展。 但是，假如遇到大促，系统还是存在一些问题需要处理，比如机器预备周期长、紧急情况无法应对；大促后机器闲置率高，资源铺张巨大。因而，乐信开头探究混合云架构，将流量大户置于公有云之上，保证机器资源按需申请；接入层按 URL 调度流量；服务层 Set 化的路由策略；数据层读恳求上云，写恳求回自建 IDC。 即便这套架构足以满足当下需求，但混合云从物理层面来看是两个机房，规律上还是一个集群，由于乐信内部的云机房和本地机房共用一套注册中心。随着流量越来越大，集群规模越来越大，单集群模式如何应对？假如发生气房级的灾难，单机房怎样办? 基于上述担忧，乐信研发团队又开头探究同城双活的处理方案，在接入层建立起用户维度的流量调度力量；统一集团 Job 调度平台、分别 service 和 job；跨机房的统一配置中心；mq 具备单元化路由及容灾力量；统一开放网关建设，划清业务板块边界；全链路系统诊断力量建设完成后，乐信的混合云 同城双活方案基本搭建完毕。 从最开头的 PHP 服务化 1.0 阶段处理单体应用架构的问题，到后来的 Java 服务化 2.0 阶段处理 PHP 技术栈连续演进遇到的顺境，再到处理大促痛点的混合云，以及处理跨机房容灾的单元化和同城双活方案。在这个过程中，乐信内部渐渐衍生动身布系统、监控告警系统、全链路诊断系统等 DevOps 相关系统，消息两头件、配置中心、定时任务调度中心、分布式文件存储系统等微服务架构必备的相关基础技术产品，以及针对微服务架构的开发测试处理方案稳态环境及配套的开发测试流程及工具。最终，这些组成了现在乐信的底层基础技术平台。 如今，乐信完成了接入层、服务层、两头件层的单元化和同城双活力量，数据层虽然也有对应的跨机房容灾，但本质上数据层还是一个中心，在同一个城市或者两个距离很近的城市，比如广州和深圳，一些对跨机房延迟不太敏感的业务还可以满足。将来，假如想做到相距千里之外的异地多活，数据单元化是一个绕不开的问题。另一方面，乐信的混合云虽然已经可以应付各种大促，但过程中还是需要投入较多人力做压测、容量评估、扩容、缩容等反复性工作，将来有望借助全链路诊断体系和自动化功能评估体系逐渐自动化完成，做到一键弹性扩缩容或自动化扩缩容。 微服务实践心得 如开篇所言，微服务的好处已经被总结过很多次，比如分而治之降低系统简单度和耦合度，各服务独立开发部署利于团队闭环、也有利于并行开发提高生产力，这些好处背后隐蔽的是一系列简单变化，这时就需要一系列支持体系来处理这些问题，包括开发、测试、部署、线上运维、线上毛病定位及业务架构分析等。 在过往四年的微服务改造过程中，乐信已经有一段时间迸发过开发测试环境问题。康彬透露，当时，开发人员在环境上花费的时间超过写代码的时间，测试人员在环境上消耗的时间超过测试时间，运维人员愈加苦痛，有多少并行需求就需要维护多少套独立开发测试环境，这些就是为了猎取微服务的好处而付出的代价。 因而，康彬认为能否接受微服