开发者学堂课程【微服务治理技术进阶：【音频】微服务的优势和在云原生时代面临的挑战】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1033/detail/15132
【音频】微服务的优势和在云原生时代面临的挑战
微服务的优势显而易见，但是随着服务数量的逐步增多，链路越来越长，也面临了新的挑战。
本次播客节选自《微服务治理技术白皮书》的第一章的第一节和第二节，即《业务发展离不开微服务治理保驾护航》和《微服务治理在云原生场景下的挑战》。
随着微服务技术的发展，微服务的概念早已深入人心，也越来越多的公司开始使用微服务架构来开发业务应用。
如果采用的当微博架构可以带来非常大的优势，微服务架构的最大的好处是它可以提升开发效率和系统整体的稳定性：
·开发部署相对简单：单个微服务的功能可以更快的更改，因为可以独立部署，影响范围更小，启动和调试各个微博的时间成本相比于家庭应用也大大减少
·横向扩展简单：根据业务的高峰低谷周期快速的横向扩展非常简单，因为单个微服务通常很小，可以随着系统整体复杂的变化更快的启动和停止
·架构升级灵活：三个微服务的内部架构可以迅速升级，因为微服务之间的松散耦合的，只面向定义好的通讯接口进行编程。这使开发团队能够基于自身的技术背景和偏好灵活选择，而不会直接影响其他应用程序、服务或团队
·更好的容错性：微服务之间可以实现更好的故障隔离，三个服务内的内存泄漏等故障不容影响其他服务，相比单体应用，一个组件故障会拖垮整个系统
但是微服务在实施过程中也很容易遇到一些难点，如果微服务治理的不恰当，反而有可能适得其反，不仅不能享受到微服务架构带来的好处，反而会因为微服务带来的系统复杂性，造成开发、运维部署的复杂度增加，进而影响开发迭代的速度，甚至影响系统的整体稳定性。我们总结了一些微服务开发实施过程中遇到的常见问题：
·服务之间使用远程调用进行通讯，这比进程内的直接调用复杂很多。由于通讯链路的复杂性，可能会出现很多不确定的问题，会出现远程调用不可用或者延迟较高的情况，开发人员需要能够处理这些偶发问题，避免影响业务。
·随业务的发展，微服务之间的拓扑图开始变得复杂，排查问题变得困难，搭建完整的开发测试环境成本也越来越大。
·当功能涉及到多个微服务模块时，迭代时需要谨慎的协调多个开发团队的迭代排期，才能保证迭代能够按时交付，达到敏捷开发的效果。
随着企业微服务化进程的逐步深入，微服务的语音深化逐步进入深水区，在这个微服务深化的过程中，我们逐步会面临一系列的挑战，总得言，我们将这些挑战分为三个大的层面，他们分别是效率，稳定和成本
我们进行微博化本身的使命是让业务的迭代更加高效，但当我们的微服务数量逐步增加，链路越来越长，如果不进行进一步的治理，那么引发的效率问题可能会大于微服务架构本身带来的架构红利，在上一章节中我们提到过在微服务实施的不同阶段，遇到的问题也不尽相同。目前阿里巴巴内部的微服务节点数量是在百万级别，在这个过程我们也积累了非常多的治理经验。
在效率上面临的挑战
在效率方面需要追求的目标是，在开发，线上运维，SDK 升级等方面更加高效。
·在开发阶段，需要考虑业务应用上云之后，如何让本地开发的应用很好的部署以上的业务进行联调？通常我们的微服务不可能在本地完整的部署一整套系统，开发的应用只是整个微服务链路的一小部分，这包括我们流量需要能够轻松的从云上，引导到本地，便于我们做开发调试，或者我们在本地能够很方便的调用云上部署的微服务进行联调。这在微服务上云之后变得比原来在自身机房进行开发联调更加困难。
·在线上运维方面，我们通常需要频繁的对微服务进行变更，这些变更通常就会引发一系列的问题，例如在白天高峰期做发布，通常都会导致业务流量出现损失，我们的研发人员不得不选择在网上业务低峰期做变更，这大大降低了研发人员的幸福指数，因为他们不得不面临熬夜加班的困境。如果能在白天大流量高峰期也能进行流量无损的变更，那么对于研发人员来说将是大大提升研发效率的事情。
·微服务框架通常会引入服务治理的逻辑，而这些逻辑通常会以 SDK 的方式被业务代码所依赖，而这些逻辑的变更和升级都需要每一个微服务业务通过修改代码的方式来实现，这样的变更造成了非常大的升级成本。以阿里巴巴为例，阿里内部一个中间件的 SDK 的升级，如果要在整个集团铺开，通常需要消耗的时间以年为单位进行统计，这里面也会消耗每个微服务应用的研发，测试等庞大的资源，效率非常低下，如果能够以无侵入的方式实现中间件 SDK 的升级，那么这会是一件非常高兴的事情。
·进入云原生体系之后，以 K8s 为主的原生体系强调集群之间的灵活调用型，以POD 为单位任意的调度资源，在被调度后，POD 的 IP 也将相应的发生变化，传统的服务治理体系，通常以 IP 为维度进行治理策略的配置，例如黑名单策略等，但是当进入云原生场景后，这些传统的治理策略都会面临失效的问题，因为 POD 一旦被重新调度，原来的治理策略都将不再使用，如何能让服务治理体系更加适应云原生体系，也是我们要面临的一大挑战
在稳定上面临的挑战
稳定大于一切，在微服务上云之后，业务高可用是我们必须要解决的问题，因此通常会在同一个地域的多个可用区进行部署，在多可用区部署的情况下，跨可用区的延时就是不可忽视的问题，我们需要思考的是业务流量需要能够尽量在同一个可用区内进行流转，同时也需要考虑的是如果一个可用区出现问题，业务流量能够尽快的流转到正常的可用区，这就对我们的微服务架构的入游能力提出了挑战。
当然我们的业务不仅需要在同一个地域里保证高可用，也需要考虑一个地域出现问题的时候，保证业务的高可用，这时我们就需要考虑业务实现同城双活，甚至是异地多活，这对我们也是一个大挑战。
第三，微服务之间的调用也需要更加的安全可信，近期层出不穷的安全漏洞，一定程度上也反映出当前上一阶段在安全方面暴露出的问题还是非常多，每次安全漏洞出现之后，中间件 SDK 的升级也是困扰业务多年的问题，同时一些敏感的数据即使在数据库层做了非常多的权限管控，由于微服务被授予的数据访问的较高权限，如果微服务的调用被恶意攻击，也可能造成敏感数据的泄露，微服务之间的调用需要更加可靠可信。
在成本上面临的挑战
首先在成本方面，业务上云遇到的最大问题就是如何最低成本的把业务迁移上云，对于一个在线业务，如果要进行停机迁移，那么轻易的成本会显得非常高，对于客户的体验也会受到影响，要在不中断业务的情况下实现平滑迁移上云，还是非常大的挑战的。
其次，当我们在业务面临急速增长流量时，迫切的需要快速弹性补充更多的资源以承载业务的高峰，当我们进入业务低峰的时候，又希望能够缩小容量，节省资源，因此云产品提供的快速灵活的弹性机制是微服务上云之后一项急需的能力。
