从一个微服务应用的成功落地，谈起一个企业需要什么样的微服务治理发展，微服务的概念早已深入人心，越来越多的企业开始使用微服务架构来开发业务应用程序。如果采用得当，微服务架构可以带来很大的优势。微服务架构最大的好处是可以提高开发效率和系统的整体稳定性：开发和部署都比较简单：单个微服务的功能因为可以独立部署，所以可以更快的改变功能，影响更小，启动和调试单个微服务的时间成本也比单个应用大大降低。简单横向扩展：根据业务的波峰波谷周期快速横向扩展非常简单，因为单个微服务通常很小，可以随着系统整体负载的变化而更快地启动和停止。灵活的架构升级：单个微服务的内部架构可以快速升级，因为微服务是松散耦合的，只针对定义的通信接口进行编程。这使开发团队可以根据自己的技术背景和偏好灵活地进行选择，而不会直接影响其他应用程序、服务或团队。更好的容错性：微服务之间可以实现更好的故障隔离。单个服务出现内存泄漏等故障，不易影响到其他服务。与单个应用相比，一个组件的故障会拖垮整个系统。但是在微服务的实现过程中，很容易遇到一些困难。如果微服务管理不当，可能会适得其反。不仅无法享受微服务架构带来的好处，反而会因为微服务带来的系统复杂性，增加开发、运维部署的复杂度，从而影响开发迭代速度，甚至影响整体系统的稳定性。我们总结了微服务开发和实现中的一些常见问题：远程调用用于服务之间的通信，比进程内直接调用要复杂的多。由于通信链路的复杂性，可能会出现很多不确定的问题，例如远程调用不可用或高延迟等。开发人员需要能够处理这些偶发问题，以免影响业务。随着业务的发展，微服务之间的拓扑图变得复杂，故障排查变得困难，搭建完整的开发测试环境的成本也越来越高。当功能涉及多个微服务模块时，需要在迭代过程中仔细协调多个开发团队的迭代进度，确保迭代能够按时交付，达到敏捷开发的效果。2.微服务成功实施的典型案例在观察了阿里云的众多客户后，我们总结了一个微服务成功实施的典型案例。某公司借助微服务架构红利实现业务快速增长：主要分析公司在业务发展的不同阶段在实施微服务过程中遇到的问题，以及如何通过微服务治理解决这些问题，从而享受到红利微服务带来的开发效率和业务稳定性的提升，进而促进业务的快速发展。（一）企业孵化期。虽然创业公司一开始业务量比较小，业务模式也比较简单，但是为了在后续的快速发展中快速迭代，而且公司的人才储备也具备微服务开发的条件，所以在初创阶段，我们选择使用微服务架构进行业务开发。在技??术选择上，如果公司的创始员工是技术出身，他们会更倾向于使用自己擅长的微服务框架。比如创始人是Dubbo的贡献者，或者是SpringCloud社区的大咖，或者是SpringCloudAlibaba的贡献者。或者ServiceMesh社区的大咖通常会选择自己擅长的微服务框架类型。另一种选择是选择市面上最流行的微服务框架，比如Java系统，会选择SpringCloud和Dubbo。在当前的招聘市场上也很容易招到熟悉相关领域的人，从初学者到专家都可以轻松招到。技术选型选定后，基于开源框架，很容易开发出初期的业务应用系统，并跑通业务流程。这个阶段的组件也很简单。简单的两三个应用，用户系统、业务系统、支撑系统，再加上注册中心、数据库、缓存，就可以开发所有的应用。对于生产级系统，在整个系统部署上线前，需要先搭建监控告警系统。监控报警系统可以帮助我们实时监控机器和应用的状态。我们可以配置预置报警规则，在机器资源不足、业务异常错误时主动报警，提醒我们第一时间处理系统中的风险和异常。保留问题现场也很重要，有助于我们快速定位和排除问题。阿里云的应用实时监控服务ARMS和日志服务SLS可以在这些场景中提供很大的帮助。使用ARMS+SLS完成监控告警系统搭建后，业务系统部署上线，完成首次成功上线，业务开始正常运行。然而，业务的发展和经营从来都不是一帆风顺的。在这个过程中，肯定会遇到很多问题。先总结一下现阶段常见的问题及解决方法：1）由于代码本身的逻辑错误，导致业务异常：此时可以通过SLS查询日志，结合ARMS分析错误堆栈，找到问题所在根本原因，修改代码并重新发布以解决问题。2）遇到性能瓶颈：直接进行扩展操作，比如应用的水平扩展，或者数据库的升级。3）发布一个新版本影响用户：因为用户量和请求量都不是太大，所以很容易找到业务低峰期，在业务低峰期发布。4）如何保证新版本的正确性：因为业务场景不复杂，内测可以覆盖所有场景，测试通过后可以直接上线测试。那么如何识别自己的企业是否处于这个阶段呢？有一系列典型特征：不超过4个应用，不超过10个应用节点，峰值不超过10QPS。（二）业务快速发展期经过创业期后，公司业务深受用户和市场欢迎，注册用户越来越多，用户使用时长和功能点越来越多，日活跃度越来越高用户。大的，甚至市场上出现了其他竞争者抄袭公司的业务，有的巨头甚至倒下参与竞争。公司业务发展非常顺利，这也意味着系统进入了高速发展期。市场发展迅速，注册用户数和日活跃用户数也在稳步上升。所有统计报告中的数字都是正面的。但带来的挑战也越来越大。这个时期也是最危险的时期：在业务快速发展中，既要保证现有业务的稳定性，又要快速迭代新功能，克服团队招聘的节奏。跟不上业务发展。这个阶段的典型特征是应用数量在5到50之间，QPS在10到1000之间。这个阶段经常遇到的问题可以归纳为两个：稳定性问题和开发效率问题。稳定性问题：用户数量增加后，系统的稳定性就变得更加重要。无论是用户在某段时间内遇到异常报错增多，还是某个功能点持续报错，进而导致系统出现一段时间的完全不可用，都会影响产品在用户中的口碑。最终，这种完全不可用的场景甚至可能成为微博等社交网络的舆论热点。开发效率问题：随着用户的增多，相应的需求也越来越多，业务场景也越来越复杂。此时，测试无法通过内测覆盖所有场景，需要加大测试力度。投放。虽然功能需求越来越多，但是要求迭代速度越来越快，因为市场上已经有了竞争者。如果他们快速复制，新功能也快速发布，业务可能无法竞争，尤其是当巨头亲自离开该领域时，他们需要跑得更快，开发得更快，测试得更快，发布得更快。那么如何解决这两个场景的痛点呢？这时候我们就可以利用微服务治理的能力来解决。1）开发和测试效率【开发环境隔离】传统的多套开发环境需要使用多套物理环境才能实现多套环境相互独立，互不干扰，但是多套物理环境的机器成本环境隔离度很高，基本不能接受。而开发环境的隔离可以通过全链路灰度的逻辑隔离方式实现，可以在不增加成本的情况下增加多套开发测试环境，助您实现敏捷开发。b.【自动化回归测试】自动化回归测试功能可以将多个测试用例连接成一个测试用例集，将上一次测试的返回值作为下一跳测试的输入参数，连接到具体的业务场景中沉淀到自动化。在回归测试中，在每次发布前运行自动化回归，验证功能的正确性，可以大大节省测试的人力成本。此外，流量录放功能可用于记录真实在线流量，沉淀为自动回归用例集，并在测试环境中回放流量，进一步提高测试用例的覆盖率。C。【服务契约】功能越来越多，迭代越来越快，API越来越复杂，团队之间的沟通效率越来越低，API文档严重过时。如果自动生成服务合约，则可以有效避免文档损坏导致开发效率低下的问题。使用以上三点后，可以低成本支持多套开发测试环境，实现自动化回归测试，大大提高开发测试节奏。2)安全发布a.【无损下线】无损下线问题的根本原因是开源微服务系统不能保证应用提供者节点在停止服务前已经通知所有消费者，不能保证在处理完所有请求后停止应用。因此，即使新发布的应用的业务代码没有问题，也可能在发布过程中影响用户体验。b.【无损上线】无损上线问题的原因是在某些场景下，服务商需要一段时间才能正常接收到大流量请求并成功返回。同时，在K8s场景下，还需要与K8s中的就绪和滚动发布生命周期紧密结合，保证应用发布过程中不出现业务错误。C。【全链路灰度】新功能上线后，可通过灰度规则控制哪些用户可以使用。这样可以优先选择内部用户来测试新功能的正确性。内部用户验证通过后，逐步扩大灰度范围，确保每项功能都经过充分验证后再全面发布给客户，屏蔽发布新功能的风险。并且当出现问题时，可以通过修改灰度规则快速回滚，这样在新版本发布时几乎没有风险。使用以上几点后，可以保证新版本发布没有问题，白天大流量场景下也可以轻松发布。白天轻松发布后，一天可以发布多次，提高了发布的稳定性和发布效率。3)屏蔽偶发异常带来的风险a．【异常实例清除】对于这些偶发的异常问题，异常清除功能可以智能判断应用中某服务商出现问题，并在一段时间内智能屏蔽掉该服务商，保证业务正常，并等待服务提供商恢复后再拨打。当某个应用节点偶尔出现异常时，可以智能屏蔽该节点，避免影响业务。节点恢复后，将继续提供服务，从而屏蔽偶发异常带来的风险。据统计，近90%的上线失败是因为发布过程，剩下10%的上线问题可能是一些偶然的原因造成的。比如偶尔的网络故障，机器I/O问题，或者某台机器超载。解决了发布时的稳定性问题和偶发异常带来的风险后，基本可以保证线上业务不会出现灾难性的问题。在业务高速发展的生死期，需要依靠这些微服务治理能力来保证业务能够快速稳定的增长，才能熬过这个生死期，成为重要的这个领域的玩家。(3)业务成熟期业务进入成熟期，业务发展进入新阶段。这时候，虽然快速发展过程中的问题依然存在，但业务量增加后，又会遇到新的问题。低成本创新：虽然发展没有以前那么快，但商业创新探索的需求依然存在。由于业务规模的扩大，创新成本也在增加。这时候不仅需要快速开发迭代，更大的需求是以尽可能低的成本进行创新探索和测试，有时需要用AB测试的方式进行实验比较。容灾多活：由于业务规模已经非常大，对治理稳定性的需求更加强烈，而且随着业务范围的扩大，应用也开始多地域、多云产品部署。同城容灾、异地多活等需求也开始出现。问题定位：任何问题都必须彻底调查。虽然当出现问题时，首先要排查的仍然是业务恢复，但是业务恢复之后的问题根源也是不可或缺的，因为排查不彻底，后面难免会出现同样的问题。风险预案：应急预案和风险防范也变得非常重要。提前做好业务保护和降级演练是很有必要的。当遇到大多数可预见的问题时，可以紧急修复。当出现不可控的问题时，方案才能通过。指实施计划，保证整体业务的可控性。从这个典型案例中我们可以看出，微服务的成功落地和业务的快速发展，离不开微服务治理的支持。在业务发展的不同阶段，会遇到不同的微服务问题，需要依靠治理能力为业务的快速稳定发展保驾护航。二、云原生场景下微服务治理的挑战1、企业上云的四个阶段随着云原生时代的到来，越来越多的应用在云上诞生和成长，并且随着越来越多和越来越多的企业开始上云，云原生也是企业实施微服务的最佳搭档。我们分析了阿里云典型客户的实践经验，业务上云通常分为部署上云、云原生部署、微服务、服务治理四个阶段。（1）我们在云部署这个阶段解决的问题是如何将原本跑在自建IDC机房的传统业务迁移到云端。通常，云厂商会提供丰富的计算、存储、网络等资源供选择。以虚拟化技术和神龙裸机服务为代表的硬件，可以满足企业客户对云迁移的丰富需求。这个阶段的重点是资源，无需对业务进行任何修改，只需要从本地迁移到云端即可。(2)云原生部署云原生是释放云计算价值的最短路径。以容器技术为代表的云原生提供了强大的调度和弹性能力，大大降低了上云成本。现阶段，我们的重点主要放在业务的云原生化改造上。随着Kubernetes成为容器编排市场的事实标准，我们需要将业务从原来的虚拟机部署方式转变为容器化方式，部署运行在K8s之上，享受云原生带来的技术红利最大程度。这个阶段的核心重点是关注容器。（3）微服务当我们的业务规模逐渐扩大时，传统单体应用很难进一步支撑业务发展，业务的迭代速度已经不能满足业务的增长。这时候就需要进行微服务化改造，降低业务耦合，提高开发迭代效率，让开发更加敏捷。在这个阶段，我们以应用为核心。（4）服务治理当微服务的规模越来越大时，如果不对微服务进行规范和整顿，很可能会出现问题。例如，每个微服务都由一个独立的团队维护。如果他们之间的依赖关系不明确，可能会出现架构循环依赖等问题。从我们的数据观察来看，当微服务节点数量超过几十个时，我们通常需要引入服务治理。通常，我们需要关注开发、测试、线上运维、安全等方面的考虑。现阶段我们以业务为核心，核心目标是进一步提高开发效率，提高线上业务的稳定性。2.云原生环境下微服务治理的挑战随着企业微服务化进程的深入，微服务云原生化逐渐进入深水区。在深化微服务的过程中，我们会逐渐面临一系列的挑战挑战，总的来说，我们将这些挑战分为三大层面，即效率、稳定性和成本。我们微服务的使命是让业务迭代更高效，但是当我们微服务的数量逐渐增多，链接越来越长的时候，如果不进行进一步的治理，由此带来的效率问题可能会大于微服务架构本身带来的架构红利。在微服务实施的不同阶段，遇到的问题也是不同的。目前阿里巴巴的微服务节点数量在百万级别，我们在这个过程中积累了很多治理经验。(1)效率上的挑战效率上要追求的目标是在开发、在线运维、SDK升级上更加高效。在开发阶段，我们需要考虑的是，业务应用上云后，如何让本地开发的应用将业务部署到云端进行联调？通常我们的微服务是不可能在本地完全部署一个完整的系统的，所以本地开发的应用只是整个微服务链路的一小部分，其中包括我们的流量需要很方便的从云端引导到本地，也就是方便我们做开发调试，也可以很方便的在本地调用云上部署的微服务联调，迁移到云端后，比在自己的机房进行联调开发难度更大。在线上运维方面，我们通常需要对微服务进行频繁的改动。这些变化通常会引起一系列问题。例如，在白天的高峰时段发布通常会导致业务流量丢失。选择在晚上的业务低峰时段进行更改，大大降低了研发人员的幸福指数，因为他们不得不面临熬夜加班的困境。如果能在白天流量高峰期无损的改流，那么这对于研发人员来说，会大大提高研发效率。微服务框架通常会引入服务治理的逻辑，而这些逻辑通常以SDK的形式被业务代码所依赖，而这些逻辑的变更和升级需要每个微服务业务通过修改代码来实现。这样的变化导致了非常大的升级成本。以阿里巴巴为例，阿里巴巴内部某个中间件SDK的升级，如果要在整个集团内铺开，通常需要花费时间以年为单位进行统计，这也消耗了各个微服务的研发和测试应用。如此巨大的资源是非常低效的。如果中间件SDK能够以非侵入的方式进行升级，那将是一件非常高效的事情。进入云原生系统后，基于K8s的云原生系统强调集群间的灵活调度，任何调度资源都是基于POD。被调度后，POD的IP也会随之变化。传统的服务治理体系，通常以IP为维度来配置治理策略，比如黑白名单策略等。但是，进入云原生场景后，这些传统的治理策略就会面临失效的问题，因为一旦POD被重新安排，原来的治理Policies将不再使用。如何让服务治理体系更加适配云原生体系，也是我们要面临的一大挑战。(2)稳定性比什么都难。上云后，业务高可用是我们必须要解决的问题。因此，它通常部署在同一区域的多个可用区中。在多可用区部署的情况下，跨可用区的延迟不容忽视。我们需要考虑的是，业务流量需要尽可能在同一个可用区内流动。同时，我们还需要考虑，如果一个可用区出现问题，业务流量能够尽快流向正常的可用区，这对我们微服务框架的路由能力提出了挑战。当然，我们的业务不仅仅需要保证同地域的高可用，还需要考虑当一个地域出现问题的时候，保证业务的高可用。这个时候就需要考虑业务实现同城双活，甚至多活，这对我们来说也是一个很大的挑战。第三，微服务之间的调用也需要更加安全可靠。近期安全漏洞的不断涌现，一定程度上也反映出当前上云阶段还暴露出不少安全和便利性问题。每次出现安全漏洞后，中间件SDK的升级一直是困扰业务多年的问题；同时，一些敏感数据，即使在数据库层做了很多权限控制，因为微服务被赋予了更高的数据访问权限，如果微服务对系统的调用进行恶意攻击，也可能导致敏感数据的泄露。微服务之间的调用需要更加可靠和可信。（3）成本方面面临的挑战首先，成本方面，业务上云遇到的最大问题是，如果以最低的成本将业务上云，对于线上业务来说，如果宕机需要迁移，那么迁移成本会非常高，客户体验也会受到影响。在不中断业务的情况下实现平滑上云，仍然是一个非常大的挑战。其次，当我们的业务面临极速增长的流量时，我们迫切需要快速的弹性添加更多的资源来承载业务的高峰。当我们进入业务的低峰期时，我们希望能够降低产能，节约资源。因此，云产品提供的快速灵活的弹性机制是微服务上云后急需的能力。
