vivo 海量微服务架构最新实践

除了上面介绍的框架和系统，业务在微服务架构改造过程中，需要的能力全貌是怎样的？

在深度参与业务微服务架构改造过程中，我们对最佳实践能力项进行了抽象，从而形成了vivo内部的微服务架构最佳实践总结-架构能力矩阵，总计近30项能力。为了更直观的呈现这些能力，我们从接入层、服务层、数据层的三层架构分层，开发、运维等DevOps的关键环节对架构能力进行了梳理，如下图所示。

在开发接口时，我们要实现内外网接口分离，保障接口的安全性，为此我们要接入网关来隔离内外网接口；在接入层和服务层，我们可以通过治理平台来实现限流、熔断、降级等能力，保障业务的高可用。

在构建内部服务时，我们要尽可能实现服务无状态，通过RPC框架实现内部接口的RPC相互调用，具备异常重试能力，提升服务的鲁棒性；在编码过程中，我们通过接入配置中心实现代码与配置分离，具备运行时动态调整配置的能力，提高服务的变更效率。

在异步调用场景，我们可以通过接入消息中间件实现业务间的相互解耦、流量削峰；在定时任务场景，我们可以通过分布式任务调度系统，实现失败任务的自动转移能力。

此外，我们可以通过落地存储与计算分离能力，实现服务层和数据层的解耦，便于分层扩容，具备面向未来更大规模业务的扩展能力。

在数据层，通过落地读写分离、冷热分离等能力，提升系统性能，节省存储成本；同时将这些能力通过研发框架进行封装，便于业务侧复用。

我们可以借助CDN实现网站的动静分离访问，减小系统的请求压力；在日常运维过程中，我们要实现服务的可灰度、可回滚；服务节点无单点；同时借助容器技术快速实现弹性伸缩能力；提升系统的故障恢复速度。

在部署时，通过部署与发布分离，可以较好规避发布变更时产生的问题，即服务部署成功，并且健康检查通过后再发布到生产环境，减小故障的影响范围。

在遇到严重的系统故障时，需要具备使用备份数据从零恢复的能力，同时对所有已知的故障场景要有对应的预案，提升系统的故障应对能力。

在数据运维上，我们要确保数据属主唯一，避免多个业务对同一个数据库进行访问；同时也要实现业务数据和大数据的存储隔离，避免相互影响。

除了以上能力之外，我们还要实现业务的安全合规，建设覆盖Metric、Trace、Log的可观测能力体系，便于对故障问题的定位排查；在多机房层面，需要具备同城双活、异地多活等跨机房容灾能力。

为了更好排查故障问题，我们在可观测领域构建了监控中心、日志中心、调用链等系统；此外，还有更好支撑服务构建、变更发布的CICD系统和IT基础设施的配置管理系统CMDB。

截止2019年，vivo基本完成了从0到1的微服务平台能力烟囱式建设。

快速构建这些能力的过程，离不开开源组件的赋能。例如微服务API网关背后的zuul，注册中心背后的ZooKeeper和etcd，RPC框架的Dubbo和bRPC；配置中心的Apollo和Nacos，流量治理的hystrix和sentinel，消息中间件的RabbitMQ和RocketMQ，任务调度的xxl-job；如下图所示。

首先是注册中心，众所周知，ZK是CP特性，在注册中心场景有较多不可用的问题，此外还有跨机房多活能力缺失，集群故障半径大等问题；写性能无法水平扩展，在大规模Dubbo服务场景中，接口级注册模型注册的数据量大，在业务高频变更期间网卡的带宽峰值会超过1000Gbps。此外还有业务易混用，功能缺失；内部的多个技术栈使用不同的注册中心，跨技术栈调用的研发运维成本高等问题。

在配置中心场景，存在应用、组件配置的变更通道不统一，故障场景配置回滚慢，变更审计日志分散，业务恢复耗时长等问题；配置变更下发的时效不满足业务要求，内部存在多套配置中心，都需要和业务研发流程打通，存在审批、审计、回滚等功能没有对齐的问题；此外在功能和安全上，还需要实现内部的配置定时生效，配置加解密等需求，配置访问通道符合公司的安全要求。

从以上的问题与挑战中可以看出，基于开源组件快速构建的微服务底层引擎在vivo的内部业务场景中存在较多的可用性、性能&容量、研发运维、功能&安全问题与挑战。

2.2 注册中心引擎升级

此外，针对注册中心的可用性、性能&容量、研发运维等问题，我们需要建设满足AP特性、支持跨机房多活的统一注册中心，使用Session+Data分离架构，Data层持久化数据，Session层处理和客户端的长连接，无状态Session层能较好收敛客户端请求，实现读写流量隔离，具备较好的横向扩展能力，真正解决注册中心的性能、容量和扩展性问题。

综上，我们需要构建Dubbo应用级服务发现能力，构建Session+Data分离的统一注册中心，内部的项目代号为vns。

从上面的技术方案分析中，我们可以看到，通过应用级注册可以彻底解决注册中心的流量突刺问题；通过Session+Data双层分离架构可以实现业务无感知的多集群拆分，有效缩小故障半径，那如何来落地呢？

在整个技术方案落地过程中，我们始终坚持业务导向原则，实现业务升级和迁移的零|低成本；采用稳妥、完善的升级迁移方案，确保过程可灰度、可回滚、可观测；大家可以看到，我们通过兼容ZK协议，最大限度的保障Dubbo业务的平滑升级，切换方案做到了可灰度可回滚可观测，在减少升级成本的同时，降低项目落地风险，最终实现ZK注册中心的完全下线。

上图左侧是我们最新的配置中心技术架构图，右侧是统一配置通道的示意图，我们通过支持应用配置与组件配置的统一配置通道，实现了配置管理能力的收敛统一，在此基础上，建设一键审批/审计/回滚等能力，实现了和内部业务研发流程的打通，减少人力运维投入；此外，在新版配置中心上，我们也实现了较多的高可用、性能、安全、可观测能力增强等业务诉求；在配置中心升级过程中，我们追求业务的无感知升级，通过兼容原有配置中心对外开放的接口，实现了新系统的平滑升级，原有系统优雅下线。

大家可以看到，和注册中心的升级方案类似，在配置中心的技术方案设计中，我们也较好的遵循了业务导向原则。

从上图左侧示意图中可以看到，我们快速构建的微服务平台存在10个以上的模块，每个模块都有独立的入口，用户使用平台的易用性很低；此外，这些模块在建设过程中，还需要重复对接云平台、单点登录、权限、工单、监控、CMDB等公共服务系统；系统审计日志分散，不便于快速定位因变更引起的问题；综上，烟囱式微服务平台存在多入口，功能重复对接，运维、研发成本高，故障排查与恢复效率低，易用性不足等问题。

要解决烟囱式微服务平台的问题，需要构建更合理的产品方案，我们对用户的使用现状进行了分析：

基于埋点数据，我们可以看到用户的访问集中在少数的几个功能上，通过整合各个系统模块高频使用的功能，建设统一的平台入口，实现系统间联动，这也给我们如何建设统一平台提供了较好的思路。

此外，在对各个模块的技术架构进行分析时，我们识别到了位于最底层、技术依赖程度最高的两个系统：配置中心、注册中心，这两个系统非常适合作为统一平台建设的技术底座。

在升级和建设过程中，我们需要保证现有业务的连续性，保障不发生因底层引擎升级和平台建设导致的可用性问题。因此，引擎升级和统一平台建设的工作需要建立在高可用保障的基础上；换句话来说，可用性是我们所有工作的底座。

在这个基础上，我们实现注册中心和配置中心的引擎升级，完成应用级注册模型升级；在这个过程中，解决底层引擎的扩展性、容量、性能、可维护性和安全性等问题；最后，我们要建设统一的微服务平台能力，实现平台间联动，构建自动/自助化使用能力；赋能业务。

大家可以看到，通过完整的方案介绍，在上图右侧我们呈现了微服务架构实践过程中的价值分层逻辑，即在可用性的基础上，提升系统的扩展性、容量、性能、可维护、安全性等能力；然后再在此基础上，交付更高的研发效率，更好的用户使用体验。

在从0到1的平台能力建设过程中，我们引入开源组件进行能力快速构建，快速交付满足业务的需求；始终坚持业务适用原则，不过度设计，支撑业务的快速迭代；以上阶段，我们称之为“拿来主义”。

在面向更大规模、海量业务实践过程中，为了解决碰到的问题与挑战，我们在开源的基础上进行增强，自研部分能力来解决亿级用户规模下内部业务的功能，性能，容量，研发流程打通等需求；这个阶段，我们称之为“实用主义”。

在技术平台迭代过程中，我们始终坚持2个原则，一是简单有效原则，坚持用最简单的解决方案来解决问题；二是迭代和演进原则，坚持平台持续迭代和演进的原则；前期基于开源组件快速搭建能力，再基于实际的业务需求和痛点来落地自研架构；在这个过程中，始终坚持业务适用，不为了技术而技术，避免大而全的技术架构。

此外，也要说明一个常见的误区，我们为什么不完全自研？vivo的微服务平台建设从开源社区获益良多，坚持不闭门造车，站在巨人肩膀上，持续引入优秀特性来支撑业务的快速发展，同时也会考虑将部分行业适用的通用优秀特性反馈给社区，和社区共同成长。

实践证明，只有足够稳健的底层技术能力才能更好支撑业务的高效迭代。在这个过程中，如何兼顾效率与质量？尊重客观规律，确保整个过程都有明确的目标和方向，避免走偏，慢就是快。

我们认为，完善的中间件组件全生命周期管理策略，首先需要在所有的技术团队中形成价值共识；再通过组件扫描和组件地图等手段及时对组件全貌进行洞察；在组件的标准化治理和运营阶段实现有规范，补短板；同时在新技术引入时，通过完善的新技术引入规范，覆盖功能/性能/容量/扩展性/成熟度/使用成本等维度；在组件的版本治理上，使用基线版本治理方案，输出明确的使用标准/版本升级方案/版本收敛策略；最后，在组件的成熟度管理上，我们可以借助Gartner(高德纳)技术成熟度说明和组件能力矩阵，不断提升组件的成熟度。

综上，为更高效的支撑业务，在组件管理上我们使用了更加入宽松的引入策略，同时也会对组件的全生命周期进行严格管理，践行宽入严出策略，通过完善的中间件组件全生命周期管理助力业务跑的更快，走的更远。

展望未来，我们会坚持和践行引擎升级和平台建设的持续迭代思路：

首先是对引擎升级的探索，通过引入新技术来解决当前碰到的研发效率、成本等痛点问题：

要解决以上问题，我们可以通过升级MQ组件，落地存算分离技术，探索计算存储资源利用率优化方案。另外，还可以探索Serverless技术，实现平台化托管运维，降低资源成本，天然适合小程序、快应用等事件驱动业务场景。

综上，在引擎升级探索上，我们会基于业务需求和痛点问题，探索和落地ServiceMesh/Serverless/存算分离等云原生技术。

作为技术平台团队，我们在持续积极的探索“平台工程”理念，从现在的DevOps实践到平台工程，也是团队协作理念的再次升级。

我们知道，DevOps于2009年出现，2015年在国内火起来，它是一种文化、方法论，是敏捷理念从开发到运维的延伸。DevOps的理念是：践行谁构建谁运行，开发运维一体化，实现业务的高效交付。

此外，从平台能力上讲，DevOps平台往往更侧重于建设流程和工具链，而在使用这些建设的工具技术平台过程中会大大增加业务开发团队的认知负荷，存在无法较好向业务开发团队屏蔽底层基础设施复杂性的问题。

平台工程的概念，是在2017年首次出现，于2022年在国内兴起。平台工程的定义是，一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构；它的特点是：平台在演进中提供足够的透明度、敏捷性，在建设过程中形成适合业务架构的高效协作模式。在这一过程中逐步将知识体系固化到平台中，从而使得工程方式标准化、流程化和规模化并持续改善；它践行的理念是：一个可用的、高效的平台并非一个技术团队埋头苦干就可以产出的；恰恰相反，一个成功的平台工程需要企业各个组织部门合作、协调、推广并根据实际使用反馈不断迭代。

在具体实践中，平台工程约定了“业务团队”和“平台团队”两个团队，其中“业务团队”负责业务研发，“平台团队”负责平台建设；“平台团队”通过将技术知识沉淀到“平台工程”，隐藏和抽象底层基础设施的复杂性，实现基础设施即代码，为“业务团队”赋能增效；同时，基于“业务团队”在使用“平台工程”的过程中的不断反馈来持续改进平台的自助化产品能力，构建一整套覆盖DevOps全链路的简单易用平台产品；可以看到，平台工程是一种最佳实践，和我们当前的团队协作模式匹配度非常高。