保持兼容,无状态服务升级,有状态服务升级,服务发现,风险防控
保持兼容开始升级之前，我们首先需要确认被升级的服务是否保持了向前与向后兼容性。保持兼容不仅减少了工作量，也减少了升级所导致的故障风险。为了尽量避免升级导致的不兼容，我们可以总结一些开发原则：[*]远程过程调用（RPC）需要能够忽略未知参数，并且允许缺失参数。
[*]如果需要删除已有参数，需要与所有依赖方确认。可以先将参数标记为 Deprecated 而不是直接移除。
[*]使用参数时，区分缺省值和缺失值。
[*]如果接口无法保持兼容，则创建新接口代替旧接口。不要破坏旧接口的兼容性。
在升级时，先升级那些没有外部依赖的服务。等到被依赖方升级完毕之后，再去升级依赖方。确定了每一个服务的升级顺序之后，我们再根据服务的实际情况确定升级方案。无状态服务升级正式进入升级流程，我们首先关注搜索链路中的被设计成无状态服务的部分，例如用于处理业务逻辑的 Java 微服务、用于处理查询逻辑的 Search Planner 等。它们的共同特点是，每个请求处理完毕之后，关于该次请求的资源即被释放。不同的请求之间没有相互依赖和时序要求。同一个无状态服务内不同的机器节点是完全等价的。无状态服务的特点使得它们很容易通过水平扩展来动态扩缩容。因此在保证兼容的前提下，它们的升级流程相对通用并且简单：
[*]根据服务最小可用度决定分批数。
[*]选取一批待更新的容器，停止服务。
[*]批量升级容器、更新镜像。
[*]等待这一批容器全部恢复服务后，继续更新下一批容器。
img.alicdn.com/tfs/TB1qBC7VUz1gK0jSZLeXXb9kVXa-1302-667.png一般来说我们可以通过把状态存储在消息队列、缓存、数据库或者其它外部中间件中来达成服务的无状态。把服务设计成无状态的好处显而易见：升级时不需要分配额外的机器资源，升级速度快，变更代价小，因而可以支持频繁的迭代更新。但是，这种设计也给状态访问和更新带来了额外的开销，在某些性能敏感的场合可能是不适用的。有状态服务升级我们继续关注有状态的部分。有状态服务升级的麻烦之处在于，状态的存储、恢复、转移往往由服务根据实际情况单独设计（或者根本没有设计），因而升级较为困难。我们可以简单列举一些相对通用的有状态服务升级可选方案。
[*]接入层网关提供热更新的能力（例如 Nginx），把状态的保持隔离在接入层内部。适合需要长时间保持状态的场景。
[*]渐进更新，新请求逐步切换到新服务上处理，旧服务处理完存量请求后销毁。适合短时间保持状态的场景（例如游戏服务、实时音视频通讯服务）。
[*]创建全新的服务副本，通过数据双写保持新旧服务状态一致，逐步用新服务取代旧服务。
在闲鱼搜索的架构中，搜索引擎本身提供的虽然是无状态服务，但是引擎内部保存了用于处理索引分区，增量进度的各种状态。最终使用的升级方案如下：
[*]使用新版本镜像创建一个完全独立的新引擎。
[*]新旧引擎全量数据同步。
[*]增量数据同时向新旧引擎发送。
[*]新引擎上线，逐步扩大承接流量的比例。
[*]旧引擎不再承接流量后下线。
img.alicdn.com/tfs/TB1GFrcVUY1gK0jSZFMXXaWcVXa-1444-844.png和无状态服务的升级相比，这种方式不仅额外使用了一倍的机器资源，而且每次升级都需要做一次复杂而繁琐的服务配置。如果服务本身不是无状态的，还需要自行编码实现切流逻辑，保证同一个用户的请求能够落到同一个集群上。整体升级成本较为昂贵，只适合更新频率非常低的服务。如果服务的更新频率较高，则应该根据服务的实际情况设计实现升级成本更低的方案。服务发现在升级过程中，服务发现机制承担着重要作用。它为我们提供了以下功能：
[*]保证分布式一致性
[*]服务优雅上下线
[*]负载均衡
[*]流量调控与请求降级
[*]同机房优先调度
[*]跨机房容灾调度
img.alicdn.com/tfs/TB1EYN1jZVl614jSZKPXXaGjpXa-828-545.png服务发现是流量调控的总阀门。一个成熟稳定的服务发现机制不仅可以有效避免发布导致的请求成功率抖动，也为发生异常时快速回滚止血提供了保证。风险防控对搜索链路的每一个集群按照依赖顺序进行服务升级、挂载、切流无疑是高危操作，稍有不慎就可能引起线上故障。因此，我们按照阿里巴巴安全生产三板斧原则对升级流程进行了梳理：
[*]可监控
重要链路的重要指标均提前保证监控覆盖。例如请求总量，请求成功率，请求响应时长等等。确保重大问题可以通过监控指标及时发现。
[*]可灰度
任何变更都不允许未经灰度直接全量发布到线上。对于无状态服务，我们一般通过调整服务发现中的权重或者调整机器比例来完成灰度放量。对于部分不能随机灰度的情形，我们设计了按用户分批放量的机制。
[*]可回滚
变更系统提供了通用的一键回滚能力，但并非是最快的方式。在很多情况下，我们在执行变更前就做好了把待更新的机器或集群在服务发现上重新挂载或移除的准备，从问题发现到恢复的时间基本是秒级的。
总结综上所述，复杂系统不停机升级的原则和流程可以概括如下：
[*]服务间解耦与隔离，确保单次升级的范围和影响可控。
[*]根据兼容性和依赖关系决定服务的升级顺序。
[*]根据服务是否无状态决定升级方式。
[*]提前准备好监控和回滚方案，灰度升级。
阿里云服务器
阿里云产品--阿里云服务器_阿里云数据库_阿里云代理分销商典名科技
提供阿里云服务器,阿里云数据库,阿里云存储,阿里云安全产品,高防IP等产品的配置推荐、报价、折扣申请以及技术售后一站式服务！
页:
[1]