大型企业微服务架构时间与运营-学习笔记

如果某一个应用实例出现 故障了，或者主机宕机，副本控制器会立即删除发生故障的应用实例，同时创建一个 新实例，如果是主机宕机则会把新应用实例调度到其他节点。应用托管平台就是利用 Kubernetes 这一功能特性实现了应用的故障自愈。

故障自愈是副本控制器的一个具体应用，运维人员需要应用组件配置一定的副本数 （Replicas）来保证其服务能力。应用托管平台定期对实际运行的副本数进行监控，并与配置的副本数做比较，如果出现异常导致某些服务实例不能正常工作，平台会自动监 控到，这时，平台会删除异常实例信息，同时启动新的 Pod 创建流程，为该服务重新 拉起一个新的实例，使实际运行的副本数与配置的副本数保持一致，这样，系统就能保 证服务稳定地按照配置的能力持续运行。

自动扩缩容指托管平台根据监控的应用运行指标自动进行应用的扩容和缩容，如在 服务负载超过设定阈值时，通过增加实例来降低已有实例的工作负载，实现系统的扩容； 而在服务负载降低至低阈值且达到持续时间之后，平台又会“杀掉”若干实例，来达到 缩容释放资源的目的。

5. 滚动升级

滚动升级指不停机升级，服务集群中的每个服务节点分批依次升级替换，在升级的 过程中不影响业务的正常使用。

平台监控

托管平台基于 cAdvisor 实现了托管平台的监控。cAdvisor 是谷歌开源的分析容器 资源使用和性能的监控工具。目前，该工具已经被 Kubernetes 集成到 Kubelet 组件 中，无须额外配置，在托管平台的工作节点集群，每个节点上都安装有 cAdvisor 服务， 除了系统使用的 CPU、Memory、存储和网络之外，cAdvisor 还记录了每个容器使 用上述资源的情况。（Dashboard已经集成）。

第一级成熟度模型为每个软件服务提供商分配一个独立的数据库实例和应用服务器 实例，数据库中的数据结构和代码可根据客户需求定制化修改，每个客户有独立的代码。 但是不同客户软件之间可以重用和共享少量可公用的组件、资源库等。这种模型相对于传统软件，在架构上没有差别。在这种模式下，我们需要为每个客户定制开发、单独部第 13 章　多租户架构 署等，很难达到规模效应。

第二级成熟度模型下每个租户也是单独部署一个应用实例，但所有租户共享一套代 码，租户通过应用提供的配置选项进行个性化设置。第二级模型是第一级的改进，也是 针对每个客户的定制化可以通过配置方式实现，而不需要维护不同版本的代码以及不同 数据库。这种模式需要供应商提供足够的资源，同时运行多个应用实例，对服务器资源 占用较多。

第三级成熟度模型下所有租户共享一个应用实例，租户通过元数据进行个性化配置， 通过访问控制策略进行租户之间的数据隔离。由于多个租户共享一个应用实例，第三级 成熟度模型减少了部署多个应用实例的资源开销，相比第一级、第二级模型提高了资源 利用率。

第四级成熟度模型提供了更好的系统扩展性，通过在租户和应用实例之间增加负载 均衡层，系统可以方便地通过增加或减少应用实例来满足租户数量以及租户业务量的变 化，满足系统的可扩展性。

多租户数据库架构

租户独享数据库方式，每个租户使用单独的一个数据库，租户数据通过数据库进行 隔离，安全性较好。通过元数据对租户数据库进行管理，租户可以方便地进行个性化的 配置。但是，由于数据库会占用较多的服务器资源，当租户数量较大时，会占用大量的服务器资源，因此，独享数据库方式资源共享度较低。

租户共享数据库独立模式，所有租户共享一个数据库实例，每个租户拥有一套自己的数据表。在这种模式下，当有新租户加入时，只需要在共享数据库中为该租户创建一 套数据表。租户数据之间通过数据表进行隔离。在资源相同的情况下，较前一种方法支 持的租户数量增加很多。但是，由于每个租户都拥有一套数据表，当租户数量较大时， 数据库中的数据表数量会大量增加，并且每个数据库支持的数据表数量有限，因此，当 数据库表数量达到一定程度时，会导致服务器性能急剧下降。