复杂系统如何在不停机升级同时保持稳定？你必须考虑以下几个点
扫描二维码
随时随地手机看文章
背景
在互联网行业，线上服务的升级更新可谓家常便饭。据统计，在过去的一个季度中闲鱼工程师们执行了千余次发布，总计更新的代码数量超过百万行。
这些发布中，有一些可能只更新了几行代码，而有一些可能执行了整个集群的迁移升级。而无论这些变更的影响面有多大，我们都必须保证线上服务的可用性，用户无感知。本文将以闲鱼搜索服务的迁移升级为例，向大家介绍其背后的技术方案。
闲鱼搜索服务基本架构
闲鱼的底层搜索服务由查询规划服务 Search Planner、查询理解服务 Query Planner、打分排序服务 Rank Service 以及搜索引擎 Heaven Ask 3 所组成。它们之间的相互调用关系如下图所示：
可以看到，整个搜索服务是由多个相互独立的微服务所构成的。不同的微服务之间相互隔离，通过预先向外暴露的接口提供服务。所有的微服务最终通过 Search Planner 收口，对外提供统一、完整的搜索能力。
在底层搜索服务之上，还有业务逻辑层和接入网关层，具体架构在此不再赘述。用户的搜索请求先通过网关层转发给逻辑层处理，再向底层搜索服务发起搜索请求。这条请求链上包含数十个集群，调用深度达到两位数，整个过程中提供服务的服务器数量可能有成百上千。
对于这样一个复杂的系统，升级过程显然无法一蹴而就。好消息是各个微服务之间合理的解耦合给升级工作带来了很大的便利，有效避免牵一发动全身而导致无从下手，使我们可以分门别类地处理升级问题。
注1：Search Planner 是一个基于函数式、服务化、可视化、并行化开发框架所构建的搜索服务网关层。
注2：Query Planner 的主要作用是理解用户输入，然后对搜索词进行算法优化。最终获得更好的搜索召回结果。
注3：Rank Service 是实时打分排序服务，它的作用是根据多维度的特征对搜素引擎召回的海选结果进行算法打分。分数越高的商品就越有机会出现在搜索结果的前列。
注4：Heaven Ask 3 （问天3）是阿里巴巴研发的一款稳定高效、功能强大的搜索引擎。为阿里集团包括淘宝、天猫在内的核心业务提供搜索服务支持。
保持兼容
开始升级之前，我们首先需要确认被升级的服务是否保持了向前与向后兼容性。保持兼容不仅减少了工作量，也减少了升级所导致的故障风险。
为了尽量避免升级导致的不兼容，我们可以总结一些开发原则：
远程过程调用（RPC）需要能够忽略未知参数，并且允许缺失参数。
如果需要删除已有参数，需要与所有依赖方确认。可以先将参数标记为 Deprecated 而不是直接移除。
使用参数时，区分缺省值和缺失值。
如果接口无法保持兼容，则创建新接口代替旧接口。不要破坏旧接口的兼容性。
在升级时，先升级那些没有外部依赖的服务。等到被依赖方升级完毕之后，再去升级依赖方。确定了每一个服务的升级顺序之后，我们再根据服务的实际情况确定升级方案。
无状态服务升级
正式进入升级流程，我们首先关注搜索链路中的被设计成无状态服务的部分，例如用于处理业务逻辑的 Java 微服务、用于处理查询逻辑的 Search Planner 等。它们的共同特点是，每个请求处理完毕之后，关于该次请求的资源即被释放。不同的请求之间没有相互依赖和时序要求。同一个无状态服务内不同的机器节点是完全等价的。
无状态服务的特点使得它们很容易通过水平扩展来动态扩缩容。因此在保证兼容的前提下，它们的升级流程相对通用并且简单：
根据服务最小可用度决定分批数。
选取一批待更新的容器，停止服务。
批量升级容器、更新镜像。
等待这一批容器全部恢复服务后，继续更新下一批容器。
一般来说我们可以通过把状态存储在消息队列、缓存、数据库或者其它外部中间件中来达成服务的无状态。把服务设计成无状态的好处显而易见：升级时不需要分配额外的机器资源，升级速度快，变更代价小，因而可以支持频繁的迭代更新。但是，这种设计也给状态访问和更新带来了额外的开销，在某些性能敏感的场合可能是不适用的。
有状态服务升级
我们继续关注有状态的部分。有状态服务升级的麻烦之处在于，状态的存储、恢复、转移往往由服务根据实际情况单独设计（或者根本没有设计），因而升级较为困难。我们可以简单列举一些相对通用的有状态服务升级可选方案。
接入层网关提供热更新的能力（例如 Nginx），把状态的保持隔离在接入层内部。适合需要长时间保持状态的场景。
渐进更新，新请求逐步切换到新服务上处理，旧服务处理完存量请求后销毁。适合短时间保持状态的场景（例如游戏服务、实时音视频通讯服务）。
创建全新的服务副本，通过数据双写保持新旧服务状态一致，逐步用新服务取代旧服务。
在闲鱼搜索的架构中，搜索引擎本身提供的虽然是无状态服务，但是引擎内部保存了用于处理索引分区，增量进度的各种状态。最终使用的升级方案如下：
使用新版本镜像创建一个完全独立的新引擎。
新旧引擎全量数据同步。
增量数据同时向新旧引擎发送。
新引擎上线，逐步扩大承接流量的比例。
旧引擎不再承接流量后下线。
和无状态服务的升级相比，这种方式不仅额外使用了一倍的机器资源，而且每次升级都需要做一次复杂而繁琐的服务配置。如果服务本身不是无状态的，还需要自行编码实现切流逻辑，保证同一个用户的请求能够落到同一个集群上。整体升级成本较为昂贵，只适合更新频率非常低的服务。如果服务的更新频率较高，则应该根据服务的实际情况设计实现升级成本更低的方案。
服务发现
在升级过程中，服务发现机制承担着重要作用。它为我们提供了以下功能：
保证分布式一致性
服务优雅上下线
负载均衡
流量调控与请求降级
同机房优先调度
跨机房容灾调度
服务发现是流量调控的总阀门。一个成熟稳定的服务发现机制不仅可以有效避免发布导致的请求成功率抖动，也为发生异常时快速回滚止血提供了保证。
风险防控
对搜索链路的每一个集群按照依赖顺序进行服务升级、挂载、切流无疑是高危操作，稍有不慎就可能引起线上故障。因此，我们按照阿里巴巴安全生产三板斧原则对升级流程进行了梳理：
可监控：重要链路的重要指标均提前保证监控覆盖。例如请求总量，请求成功率，请求响应时长等等。确保重大问题可以通过监控指标及时发现。
可灰度：任何变更都不允许未经灰度直接全量发布到线上。对于无状态服务，我们一般通过调整服务发现中的权重或者调整机器比例来完成灰度放量。对于部分不能随机灰度的情形，我们设计了按用户分批放量的机制。
可回滚：变更系统提供了通用的一键回滚能力，但并非是最快的方式。在很多情况下，我们在执行变更前就做好了把待更新的机器或集群在服务发现上重新挂载或移除的准备，从问题发现到恢复的时间基本是秒级的。
总结
综上所述，复杂系统不停机升级的原则和流程可以概括如下：
服务间解耦与隔离，确保单次升级的范围和影响可控。
根据兼容性和依赖关系决定服务的升级顺序。
根据服务是否无状态决定升级方式。
提前准备好监控和回滚方案，灰度升级。
闲鱼搜索服务升级的整个执行过程经历了两个月的时间。这其中我们既保证了用户无感知，线上服务稳定运行，也保证了与我们合作开发的算法团队以及其他工程团队的正常开发不受影响。
在实际执行的过程中，我们还遇到了很多细节上的问题。例如创建新服务时未能提前合理预估预算需求，导致升级过程中不断挪借预算，拆东墙补西墙。又比如异地多活部署带来的延迟问题迫使服务保持单元化，给升级过程中的流量调控工作带来了很多挑战。这些暴露的问题也为我们继续完善架构和方案提供了指引。
希望本次的分享能够给大家带来一些帮助和启发。
特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：
长按订阅更多精彩▼
如有收获，点个在看，诚挚感谢
免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！
下载文档
