1.2 服务治理在云原生场景下的挑战

企业上云的四个阶段

随着云原生时代的到来，越来越多的应用生在云上，长在云上，且随着越来越多的企业开始上云，云原生也是企业落地微服务的最佳伴侣。

我们分析了阿里云典型客户的实践经历，业务上云通常划分为4个阶段：云上部署、云原生部署、微服务化、服务治理。

云上部署

这一阶段我们解决的问题，如何把传统业务，原来是跑在自建 IDC 机房的业务，能够原封不动的迁移到云上。通常云厂商提供了丰富的计算，存储，网络等资源可供选择，以虚拟化技术，神龙裸金属服务为代表的硬件可以满足企业客户上云搬迁的丰富需求，这一阶段关注的焦点是资源，对于业务并无任何的改造，只需要从本地原样搬迁到云上即可。

云原生部署

云原生是释放云计算价值的最短路径，以容器技术为代表，云原生提供了强大的调度，弹性等能力，极大的降低了上云的成本。这一阶段我们关注的目标主要是业务进行云原生化改造，随着 kubernates 作为容器编排市场的事实标准，我们需要把业务从原来的的虚拟机部署方式改造成容器化方式，部署并运行在 k8s 之上，最大限度享受到云原生带来的技术红利。这一阶段核心关注目标以容器为核心。

微服务化

当我们的业务规模逐步扩大，传统单体应用很难进一步支撑业务的发展，业务的迭代速度已经无法满足业务的增长，此时我们就需要进行微服务化的改造，降低业务的耦合度，提升开发迭代的效率，让开发更加敏捷。这一阶段我们聚焦以应用为核心。

服务治理

当微服务的规模也越来越大的时候，如果对微服务不加以规范和整治，很容易出现问题。例如，每个微服务都有独立的团队来维护，他们之间如果依赖没有整理清楚，可能会出现架构上循环依赖等问题。从我们的数据观察来看，当微服务的节点数超过数十个的情况下，我们通常就需要引入服务治理，通常需要关注的是开发，测试，线上运维，安全等多方面考虑，这一阶段我们聚焦以业务为核心，核心目标是进一步提高开发效率，提高线上业务的稳定性。

微服务治理在云原生下的挑战

随着企业微服务化进程的逐渐深入，微服务的云原生化逐步进入深水区，在这个微服务深化的过程中，我们逐步会面临一系列的挑战，总的而言，我们将这些挑战分为三个大的层面，他们分别是效率，稳定，和成本。

我们进行微服务化，本身的使命是让业务的迭代更加高效，但当我们的微服务数量逐步增多，链路越来越长，如果不进行进一步的治理，那么引发的效率问题可能会大于微服务架构本身带来的架构红利。在上一章节中我们提到过在微服务实施的不同阶段，遇到的问题也不尽相同。目前阿里巴巴内部的微服务节点数量是在百万级别，在这个过程我们也积累的非常多的治理经验。

在效率上面临的挑战

在效率方面需要追求的目标是，在开发，线上运维，SDK升级等方面更加高效。

• 在开发阶段，我们需要考虑的是，业务应用上云之后，如何让本地开发的应用，很好的部署云上的业务进行联调。通常我们的微服务不可能在本地完成的部署一整套系统，所以本地开发的应用只是整个微服务链路的一小部分，这包括我们的流量需要能够轻松的从云上，引导到本地，便于我们做开发调试，或者我们在本地能够很方便的调用云上部署的微服务进行联调。这在微服务上云之后，变的比原来在自身机房进行开发联调更加困难。
• 在线上运维方面，我们通常需要频繁的对微服务进行变更，这些变更通常就会引发一系列的问题，例如在白天高峰期做发布，通常都会导致业务流量出现损失，我们的研发人员不得不选择在晚上业务低峰期做变更，这大大降低了研发人员的幸福指数，因为他们不得不面临熬夜加班的困境。如果能在白天大流量高峰期也能进行流量无损的变更，那么这对于研发人员来说将是大大提升研发效率的事情。
• 微服务框架通常会引入服务治理的逻辑，而这些逻辑通常会以 SDK 的方式被业务代码所依赖，而这些逻辑的变更和升级，都需要每一个微服务业务通过修改代码的方式来实现，这样的变更造成了非常大的升级成本。以阿里巴巴为例，阿里内部一个中间件SDK的升级，如果要在这个集团铺开，通常需要消耗的时间以年为单位进行统计，这里面也会消耗每个微服务应用的研发，测试等庞大的资源，效率非常底下，如果能够以无侵入的方式实现中间件 SDK 的升级，那么将会是一件非常高效的事情。
• 进入云原生体系之后，以 k8s 为主的云原生体系强调集群之间的灵活调度型，以 POD 为单位任意的调度资源，在被调度后 POD 的 IP 也将相应的发生变化，传统的服务治理体系，通常以 IP 为维度进行治理策略的配置，例如黑白名单策略等，但是当进入云原生场景后，这些传统的治理策略都会面临失效的问题，因为 POD 一旦被重新调度，原来的治理策略都将不再使用，如何能让服务治理体系更加适应云原生体系，也是我们要面临的一大挑战。

在稳定上面临的挑战

稳定大于一切，在微服务上云之后，业务高可用是我们必须要解决的问题，因此通常会在同一个地域的多个可用区内进行部署，在多可用区部署的情况下，跨可用区的延时就是不可忽视的问题，我们需要思考的是业务流量需要能够在尽量在同一个可用区内进行流转，同时也需要考虑的是如果一个可用区出现问题，业务流量能够尽可能快的流转到正常的可用，这就对我们的微服务框架的路由能力提出了挑战。
当然，我们的业务不仅需要在同一个地域里保证高可用，也需要考虑一个地域出问题的时候，保证业务的高可用，这时我们就需要考虑业务实现同城双活，甚至是异地多活，这对我们来说也是一大挑战。
第三，微服务之间的调用也需要更加的安全可信，近期层出不穷的安全漏洞，一定程度上也反应出当前上云阶段在安全方便暴露出的问题还是非常多，每次安全漏洞出现之后，中间件 SDK 的升级也是困扰业务多年的问题；同时，一些敏感的数据，即使在数据库层做了非常多的权限管控，由于微服务被授予了数据访问的较高权限，如果微服务的调用被恶意共计，也可能会造成敏感数据的泄露。微服务之间的调用需要更加可靠可信。

在成本上面临的挑战

首先，在成本方面，业务上云遇到的最大问题就是如果最低成本的把业务迁移上云，对于一个在线业务，如果要进行停机迁移，那么迁移的成本会显得非常高，对于客户的体验也会收到影响，要在不中断业务的情况下，实现平滑迁移上云，还是有非常大的挑战的。
其次，当我们在业务面临极速增长的流量时，迫切的需要快速的弹性，补充更多的资源以承载业务的高峰，当我们进入业务低峰的时候，又希望能够缩小容量，节省资源，因此云产品提供的快速灵活的弹性机制，是微服务上云之后一项急需的能力。