抗住“亿级流量”—微服务高可用架构演化

Posted 2021-04-24 蟋蟀得不像砖家派

l 前言

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

软件架构师Chris Richardson曾一针见血地指出:“微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间的通讯机制。此外，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题【数据及时&数据一致性】。

在组织的业务系统向微服务架构演变的过程中，存在很多问题需要解决。

我拿一家SCRM SaaS【云来】公司从 0 到 1 进行团队搭建并主导推动多轮系统架构演变的亲身经验。

简单用几张图来展示产品的价值和技术架构的拓扑图：

l 由0到1微服务历程

云来数字化系统构建第一年，基本每天都在救火，因为会遇到各种新问题，可能是因为基础技术产品缺失，也可能是已有基础技术产品存在缺陷，或者业务研发同学使用不当等。总之，每天都在解决各种问题，被各种问题驱动向前不断迭代。

云来是一家互联网新零售数字化服务商，旗下主要业务包括微信接入、门店导购、超级货架、智能数据几大模块。

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

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

随后，云来对系统进行了微服务改造，如下图，最底层是由运维团队提供的各种资源，包括计算资源、存储资源、网络资源等。中间件层主要分为微服务框架、消息中间件以及 Job 调度系统三部分。其中，微服务框架解决的是同步调用问题，消息中间件解决的是异步调用问题，调度系统解决的是后台计算逻辑，比如不同客户相关统计报表等问题，其上承接两大平台——货架交易平台和导购协作平台，共同提供了获客、沉淀、IM、下单以及复购等基础中台能力，这些基础中台能力支撑着上层各种前台业务的快速发展。

但是，如果遇到大促，系统还是存在一些问题需要解决，比如机器准备周期长、紧急情况无法应对；大促后机器闲置率高，资源浪费巨大，那么将大客户的流量置于云上，保证资源快速按需进行申请扩容成为应对大客户的必需。

l 云化-“混合云”

 

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

l 云化-“同城&异地双活”

 

当企业的业务原先即已部署在阿里云上，可采用阿里云的公共云同城容灾解决方案，使用阿里云DNS、SLB等产品，搭建同地域多可用区容灾系统架构，实现同城容灾。如上图部署架构，同城双活是多套线上环境进行业务响应，组合方式有很多种。譬如，本地IDC+云部署\云+云的方式。当某一套出现问题后，接入层能快速进行切换。

同城&异地多活，既能起到线上负载均衡的作用，也能让不同地域的用户根据位置选择最近的应用服务来进行服务。相比于同城&异地容灾而言，容灾机器只进行守护，不会提供生产，当出现异常时才能进行切换，试想，真正出现故障的时候，谁能真正拍板切换，可能切换后发生很多未知的风险，应用太多，两边的同步是否真正的一致。这些东西都是具备风险性的。而且灾备集群在正常环境下是很少进行利用的，服务器利用率得不到充分的利用。

在同城不同可用区之间对原有应用架构做一套完整的备份，SLB、ECS、RDS等均在两个机房同时部署。

云同城容灾\架构优势

可用区之间高速、低延时互联，快速复制数据。

可用区之间配置网络一体化环境，方便发布、部署、配置变更等工作。

负载均衡（SLB）支持多可用区实例，产品化实现容灾及切换。

SLB可直接同时挂载多个可用区的ECS，实现负载均衡及容灾切换。

数据库支持多可用区实例，产品化实现灾备切换。

带来的挑战

从最开始的 PHP 服务化 1.0 阶段解决单体应用架构的问题，到后来的 Java 服务化 2.0 阶段解决 PHP 技术栈继续演进遇到的困境，再到解决大促痛点的混合云，以及解决跨机房容灾的单元化和同城双活方案。在这个过程中，线上发布系统、CI\CD\devops这些基础设施必须得跟起来。靠以往的人肉发布想想每次上线都是非常大的工程。对于每个发布前的单元化自动冒烟测试，难道靠人工来回归~~~~

云来内部逐渐衍生出发布系统、监控告警系统、全链路诊断系统等 DevOps 相关系统，消息中间件、配置中心、定时任务调度中心、分布式文件存储系统等微服务架构必备的相关基础技术产品，以及针对微服务架构的开发测试解决方案稳态环境及配套的开发测试流程及工具。最终，这些组成了现在云来的底层基础技术平台。

 

l 弹性扩容-“单元化”

 

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

未来有望借助全链路诊断体系和自动化性能评估体系逐步自动化完成，做到一键弹性扩缩容或自动化扩缩容。

l 总结

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

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

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