从亚马逊“干掉”微服务说起——微服务管理的复杂性

亚马逊的 Prime Video 团队前一段发布了一则案例研究，用单体架构取代微服务架构，为他们节省了 90% 的运营成本。这无疑给众多人鼓吹的微服务当头一棒。为什么微服务和我们的期望相去甚远？微服务架构真有这么不堪吗？采用微服务需要理解微服务的初衷是什么？应用微服务的难点和陷阱在哪里？单体和微服务架构的适用场景有什么不同？等等问题，否则就是瞎用。 谈微服务我们不得不谈采用微服务架构的初衷，也就是为什么要采用微服务。不是人家采用微服务我们就必须采用微服务，人家说微服务弹性伸缩好我们就必须用弹性伸缩。微服务好或不好，在于其应用场景。每种技术都有其适用场景，适于解决某一种类型的问题。就像一个人，有擅长的也有不擅长的领域。文武全才的毕竟是凤毛麟角，而微服务并不是文武全才，其自有其弱点，因此，在应用微服务的时候并不能偏离微服务架构设计的初衷，为了微服务而微服务。

微服务的初衷

微服务是一种应用分布式架构方式，其初衷是为了解决复杂单体系统敏捷变更的难题。将一部分复杂单体系统的功能分解出来，以分布式松耦合架构，实现敏捷的变更。所以微服务架构的目的是为了化繁为简，以解决经年累月积累导致庞大繁杂的单体系统所带来的响应变更缓慢的问题。对于一个功能简单的系统来说，用不用微服务架构，其实都关系不大。对于一个复杂的系统，这个系统的某些功能组件又面临着频繁的更新需求，微服务架构才是合适的。就像一辆汽车，是一个复杂的系统，由众多的零部件组装而成，有经常需要换的比如机滤、空滤、雨刮器等；也有不变的组件，比如车架底盘等。不同组件的功能和需求不一样，所以其规格、标准等也是不一样的。采用微服务架构时也是一样的道理，服务的设计和划分要基于实际的需求来确定，服务的大与小、功能范围等是基于实际是否需要敏捷变更，是否能作为一个独立组件来确认的。

敏捷变更

敏捷变更应是采用微服务架构最初始的需求。采用微服务所带来的松耦合、弹性和技术多样性等都是额外带来的优势，同时也需要意识到在某种场景下也可能成为劣势。比如说技术多样性的初衷是为了适应企业内不同的技术路线系统集成需求，但这也带来了多种技术路线的集成和融合成本。对于不是特别庞大的企业，或者业务在单一技术路线能够解决的情况下，单一的技术路线将节省大量的学习成本和管理协调成本，而采用多种技术路线将使简单的问题复杂化。 基于敏捷变更的核心需求，在解构单体系统时，或者构建新微服务架构系统时，微服务的设计和划分是个关键的课题。微服务划分合理、粒度合适则会提升服务之间的协同效率，提升性能；否则会导致链路增长，性能下降，也可能会导致资源的浪费和费用的增加。这也是 Prime Video 团队曾经面临的问题。

微服务的粒度和部署架构

单体架构和微服务架构并不相悖，一个单体也可能是整个复杂分布式系统中的一个微服务组件，就像人类社会一样，每个人都是一个单体，一个个单体组成了复杂的社会系统。而每个人本身又是一个复杂的微服务系统体系（一个人是由众多的人体器官组成）。因此，在进行系统微服务架构设计时，需要考虑服务的部署架构、弹性伸缩要求、基础设施支持、可迁移性等来确定服务的粒度。从数据层面，基于企业或行业主数据进行微服务拆分是一种简单的方式，这是一种自上而下、从全局到局部的设计方法，优于领域驱动设计方法。微服务设计架构和部署架构并不总是一致。部署架构往往需要根据业务实际情况进行重新规划和设计。在业务流量小的情况下，所有的服务可以打包成一个单体组件，无需分布式部署，无需服务间复杂的通信，这也要求微服务的设计能够收放自如，支持多种场景下的部署架构，按需进行打包和部署。而在业务流量很大的情况下，需要分布式部署相关的微服务，合理设置服务资源配置，优先纵向资源扩容，然后才需要考虑实例的横向弹性扩容。使用容器部署也是一样的道理。不要以为使用容器更节省资源，恰恰相反，使用容器如果配置不当，会更浪费资源，也使服务管理复杂化。软件架构和部署架构也是两回事，在部署的时候，多个微服务可能作为一个整体部署在一起，也可根据实际需要进行分开部署，这并不是一成不变的，而是要基于实际的场景和环境进行决策。不同的部署架构要求，对微服务的设计要求就不一样。从性能角度来说，多个服务部署在一起，服务之间是可以紧耦合的，这样延迟最小，性能才能最好（当然也取决于代码质量等）；如果分布式部署，就需要考虑服务之间的通信：通讯协议、交互方法等等，所以微服务的粒度不是越小越好，根据实际场景合适才是最好的。 在服务部署到不同的场景中时，需要考虑微服务的可迁移性。在一个场景可能运行良好的微服务部署到另一个场景，就可能存在性能等问题，这可能就是服务粒度划分的不合理导致的，或者部署架构不合理导致的；随着服务请求量的增加，微服务需要扩展。服务扩展有横向扩展和纵向扩展两种方式。我们谈微服务时都已经习惯了弹性伸缩，横向扩展实例。但现实实践结果表明，这并不是一种好的方法，特别是在微服务划分粒度不合理和资源配置不合理的情况下，更是一地鸡毛。微服务扩展首选纵向扩展，实现资源的弹性，然后才是横向扩展，实现服务实例的弹性。在采用微服务的时候我们总强调弹性，但弹性的适用场景是变化的流量，如果流量是稳定的或变化不大，弹性对于微服务来说就失去了价值。在一个实例能够处理请求流量的时候，为什么非要部署很多个小资源的实例来再多一步请求分发？因此，优先要考虑微服务部署单个实例的资源配置，设置合适的资源才能真正高效处理请求和节省资源。微服务一定是一个完整的组件服务，而不是一个 “ 小”服务。在某些情况下，多个微服务可能需要变体为一个微服务，作为单体而部署。

自服务敏捷基础设施

很多人在鼓吹微服务时偏离了微服务的初衷，为了微服务而微服务，也就导致在落地微服务架构时没有考虑与微服务相关的基础设施建设，导致微服务研发和管理失去控制，相对于单体系统，不但没有节省成本，反而增加了管理的复杂度，浪费了资源。微服务架构是分布式架构，采用微服务往往看重的是其弹性、轻量（和容器结合）和变更的敏捷性，却有意或无意忽略其复杂性和必要基础设施的支持。比如说要实现弹性，则往往需要容器平台的支持，引入容器平台势必使整个系统复杂化，资源需求也可能更大，特别国内一些厂商的容器平台动辄几十台服务器要求，非常的夸张。本来轻量容器和微服务反而变的异常复杂和笨重，有违初衷。还有就是很多人对容器和微服务认知有限，不知道采用微服务架构额外需要很多的基础准备工作、需要基础设施的支持。无论从应用服务角度的弹性伸缩，或者容器层支持应用服务弹性伸缩要求基础设施资源的弹性支持，都是需要考虑自上（业务应用服务）而下（基础设施资源）的能力适配。因此，自服务敏捷基础设施的建设是很重要的步骤，是支撑企业微服务架构、云原生能力，实现真正的弹性伸缩、敏捷响应的基础。自服务敏捷基础设施是当前很多人鼓吹的平台工程中的一部分。概念越多问题越多，核心关键是自己要融会贯通，平滑落地。

微服务到云原生

随着云计算技术的逐步成熟，和一些云计算公司为自身发展大力推动业务上云有关，微服务被当作了云原生很关键的一项技术，来解决云上业务的轻量化、敏捷化和弹性伸缩需求等。云原生的核心是应用，然后选择合适的技术来支撑这些应用，用到的技术就统称为云原生技术。很多公司和协会为了推广自己的技术，所以就出了很多的概念和理论，导致云原生整个体系相对很复杂，在采用云原生技术的时候，也不是仅仅有微服务、容器、 devops 和 servicemesh 就够了。厂商都是以自有产品为中心来构建自己的方案，和客户的环境并不匹配，有时候差别很远，因此作为客户在采用云原生技术的时候，需要基于自身的实际，以“客户“为中心构建云原生方案和体系，这样才能建设适合自身业务发展的云原生技术支撑体系。微服务架构可以用来构建敏捷的业务应用服务体系，实现更多服务的复用和共享，从而构建企业服务中台体系，积累敏捷响应业务变化的能力。微服务架构也可以按需重构遗留单体应用系统，实现从数据层面的融合，消除数据孤岛。

总的来说，不是微服务好不好，而是怎么用的问题。容器、微服务等都是工具，用好了则带来效率的提升，用不好可能反累其身。采用微服务会带来服务管理的复杂性，但同时也会带来敏捷、弹性、轻量等助力业务敏捷响应，促进企业的转型和发展。