网易云原生架构实践之服务治理.docxVIP

网易云原生架构实践之服务管理 在优化了版本把握策略，研发并集成了自动化构建和发布工具，实现“项目工程化”之后，网易云开头了分布式服务化架构的探究，期望处理支撑海量用户及产品高速迭代需求下的软件研发成本高、测试部署维护代价大、扩展性差等问题。 业务模块的独立，自然而然构成了基于 Docker 容器的微服务架构。网易云简化的微服务架构如图 1 所示，包括服务注册与发觉、分布式配置管理、负载均衡、服务网关、断路器等模块。 图 1 微服务架构 一个产品通常由多个应用组成，容器只是供应一个应用服务的力量，需要把多个应用组合编排起来才能供应服务。在服务编排上，网易云选择开源的 Kubernetes 。Kubernetes 是自动化编排容器应用的开源平台，这些操作不只包括部署、调度和节点集群间扩展，还包括服务发觉和配置服务等架构支持的基础力量。Kubernetes 对应用层面的关注、对微服务、云原生的支持及其生态，正是网易云所需要的。 网易云服务管理策略 在微服务架构下，随着业务渐渐简单，服务数量越来越多，引入的问题也越来越简单。如何在业务进展的同时保障服务的 SLA 和最大化利用机器资源，是摆在网易云面前一个很大的挑战。我们需要一个统一的服务管理机制对全部服务进行统一管控，保障服务正常运转。 服务管理范围掩盖了服务的整个生命周期，从服务建模开头，到开发、测试、审批、发布、运转时管理，以及最终的下线。我们通常说的服务管理次要是指服务运转时的管理，一个好的服务管理框架要遵照“在线管理，实时生效”准绳，只要这样才能真正保障服务全体质量。下面引见服务管理策略在服务运转时的应用。 服务越来越多，配置项越来越多，利用统一注册中心处理服务发觉和配置管理问题。 服务之间存在多级依靠，靠人工已经无法理清，还要避开潜在的循环依靠问题，我们需要依靠管理机制，支持导出依靠关系图。 服务的功能数据和健康形态数据是服务管理的重要依据，比如访问量、响应时间、并发数等，因而需要有监控、健康检查和统计服务。 当一个服务的访问量越来越大，需要对服务进行扩容，然后在客户端进行流量引导和优先级调度。 面对突发流量，已经无法通过扩容处理问题时，要启用流量把握，甚至服务降级。 随着业务持续进展，要提前进行容量规划，结合服务监控数据，以确认当前系统容量能否支撑更高水位的压力。 等越来越多的微服务上线之后，从平安角度看，我们需要实施明确的权限把握策略和服务上下线流程。 通过一系列的服务管理策略，最终通过数据证明系统对外承诺的 SLA。 网易云典型服务管理实践 弹性扩缩容 基于负载均衡的应用弹性伸缩方案，只需将应用系统设计成无形态，在需要伸缩的时候修改负载均衡代理配置，就可以便利地水平扩容应用系统，提高系统承载力量。 在云原生应用架构里，我们其实有更多的选择。对于无形态服务，协作云平台供应的 AutoScaling 力量，能够快速弹性扩容，实施 DevOps。在这里，弹性扩缩容是一种重要的服务管理手段。网易云选择基于 Kubernetes 的 AutoScaling 机制实现弹性伸缩。 网易云接受 Kubernetes 实现应用管理，而 Kubernetes 的 Horizontal Pod Autoscaler （HPA）组件特地设计用于应用弹性扩容的把握器，它通过定期轮询 Pod 的形态（CPU、内存、磁盘、网络，或者自定义的应用目标），当 Pod 的形态连续达到提前设置的阈值时，就会触发副本把握器，修改其应用副本数量，使得 Pod 的负载重新回归到正常范围之内。如图 2 所示。 (点击放大图像) 图 2 基于 Kubernetes 的弹性扩缩容 例如促销活动服务的应用层是一个无形态应用，当前有两个副本，我们把弹性扩容的 CPU 使用率阈值设置为 50%。但是促销当天涌入的流量远远超过预期，使得两个副本的 CPU 使用率分别达到了 80%以上，HPA 把握器监控到这种变化，于是通知副本把握器将促销活动服务的副本数量升到 4 个。当流量峰值过后，4 个副本的 CPU 使用率渐渐降到 10% 以下，HPA 把握器计算得出两个副本即可满足负载要求，于是通知副本把握器将应用副本数量变为 2。 HPA把握器的副本伸缩算法可以参考Kubernetes文档。 熔断机制 微服务架构中，各服务通过服务发觉的方式相互依靠，虽然从单个服务看来能获得格外好的隔离性，不会由于某个进程或者服务宕掉对其他服务形成直接影响，但是从业务角度来看，单个服务实例毛病还是可能形成业务访问消灭问题，轻则影响服务调用方消灭延迟和负载上升，重则形成业务全体特别。 比如，一个简约的电商场景，用户通过网站下单购买一件商品，首先将调用订单服务生成一个订单，调用领取网关完成领取，最终调用库存服务将库存量减去。在这一系列服务调用过程中，任