关于“什么是微服务”这个问题，其实并没有统一的认识。这些年来，不同背景的朋友们在不同的场合都在讨论微服务。但我们谈得越多，就越意识到我们不是在谈论同一件事。与DevOps一样，“微服务”是一个非常宽泛的术语。本文从“微服务”概念的来源入手，归纳出四种常用的微服务定义。1.JamesLewis原版微服务的6大特点。这个版本起源于2012年，这里首先要注意年份。那时候还没有Docker，Netflix的微服务流程也是在这个概念提出之前——2008年就开始了。是啊，那时候DevOps还没发明呢。JamesLewis在波兰克拉科夫举行的第33届学位会议上分享了一个名为“微服务-Java，Unix之道”的案例。在本次分享中，JamesLewis分享了他在2011年参与的一个项目中采用的一系列实践，用UNIX的哲学重新审视企业级Java应用，并将其中一些称为“微服务”。此时用于微服务的词与我们现在使用的微服务一词不同。一方面，使用Micro作为形容词是相对于Monolithic而言的，而不是相对于Macro而言，后者起源于操作系统的大学课程。我们知道，现代操作系统课程都是以UNIX为例来讲授的。而这两个词来自“Micro-Kernel”和“Monolithickernel”的对比。而不是常见的“微观经济学”和“宏观经济学”中对应的两个词Micro和Macro。另一方面，服务被复数表示不止一个。由于中文单数和复数是同一种类型，我们在翻译的时候会遇到问题。因此，当“微服务”作为一种架构形式出现时，我们就称之为“微服务架构”。为了从概念上区分单微服务和SOA等领域的“服务”，会用“单微服务”来区分。而“微服务”被单独拿出来作为一系列技术实践的总称。在这次分享中，JamesLewis将实践过的“微服务架构”总结为6大特点：1.Smallwithasingleresponsibility——“Smalltoonlyasingleprinciple”在这个特点中，微服务有多小是毋庸置疑的二标准：第一个标准是，如果一个类比开发人员能够理解的更复杂，那么它就太大了，需要进一步拆分。第二个标准是：如果小到可以随时扔掉重写，而不是继续维护遗留代码，那么它就足够小了。这个标准的一个很重要的原则是RewriteoverMaintain，即“rewritingisbetterthanmaintenance”。2.ContainerlessandinstalledaswellbehavioredUnixservices——“去容器化并作为Unix服务安装”在这个特性中，JamesLewis提倡将Jetty等工具集成到Maven中，这样可以方便地调试或部署，然后packaged创建一个可执行的JAR包，作为UNIX守护进程在系统启动时执行。尤其是在像AWS这样的公有云环境中，将这样的应用程序与虚拟机实例的初始化脚本结合起来。应用程序的生命周期和虚拟机的生命周期是绑定在一起的。由于daemon进程在所有Unix系统中都是通用的，简化了整体架构的开发和运维。3.位于不同的VCS根目录——“分布在不同的版本控制代码库”在这个特性中，JamesLewis提到了应用程序的分离。他认为一个“微服务”应该与另一个服务完全集成。隔离，当然是指从代码库一开始就隔离。他还要求开发者看到相同点和抽象点，采用单一领域来指导开发团队的开发。所以接下来他继续讨论领域驱动设计领域驱动设计和康威定律的重要性。他认为边界上下文应该足够清晰，但可以重叠。如果无法在域之间实现清晰度，请通过“物理方法”来实现——分离不同的团队。这不可避免地会带来一些公共代码，但是把这个公共代码当作一个“库”和“基础设施即代码”，就像你的代码中使用的开源软件一样。并构建一个nexus库来存储那些二进制依赖项。4.Provisionedautomatically——“自动初始化”自动初始化的重点不在于如何自动化，因为不同的应用程序和不同的平台有不同的初始化方法。这里的重点是管理分布式应用程序的复杂性。因此，对于每个服务，都可以声明这些初始化。例如：服务A，需要一个负载均衡器，并且可以自动缩放。服务B也以相同的方式声明。这些声明可以通过基础架构即代码技术得到很好的管理。5.Statusawareandauto-scaling——“Focusonstatusandauto-scaling”在这里，他认为这些应用应该能够感知吞吐量监控指标来进行自我缩放。对于一个现代应用来说，这是一个基本的架构需求，但是需要团队具备一定的DevOps能力。因为这不仅需要开发者将应用做到无状态，还需要基础设施及时捕捉环境的变化。6.Theyinteractviatheuniforminterface——《Theyinteractthroughauniforminterface》在这里，James建议大家使用成熟的HTTP协议和标准的媒体类型进行接口交互，而不是其他方式。并使用HEATOS构建RestfulAPI，使其成为超媒体应用状态引擎。这样就可以将状态和执行过程分离，更容易横向扩展。此外，它还构建了一个避免架构孵化并可以独立于客户端继续发展的层。在结论中，它特别提到了UNIX哲学。引用DougMcIlroy的采访：每个人都开始提出UNIX哲学。编写只做一件事并把它做好的程序。编写程序以协同工作。编写处理文本流的程序，因为这是一个通用接口。”那些构成工具方法的想法在管道之前以某种未成形的方式存在，但后来它们真正融合在一起。管道成为这种UNIX哲学的催化剂。“事实证明，工具的事情实际上是成功的。有了管道，许多程序可以一起工作，也可以远距离一起工作。”从这段话中，我们看到了“微服务架构”与UNIX哲学的联系：责任独立：让多个程序（注意Programs不是Program）做好一件事统一接口：文本流是一个统一的接口，每个程序都可以通过一个统一的接口消费公共通信：使用管道企业级Java应用系统中的理念，可以说虽然应用场景变了，但是UNIX分解复杂的方式和保持简单的思想没有变。最后，JamesLewis将以上六个特性转化为一个六边形的业务能力：部署为具有标准化应用程序协议和消息语义的无容器OS服务，这些服务可自动扩展并为故障而设计翻译是：微服务可以重写，而不是维护分布式有界上下文，并部署为操作系统服务，无需应用程序容器。并且具有标准化的应用协议和消息语义，它是为失败而设计的，可以自动扩展。2.MartinFowler&JamesLewis合作版中微服务的九大特性在JamesLewis之后，许多不同的项目也采用了“微服务”作为实践名称。但是，不同的项目之间还是存在一些差异的，每个人都在用自己的方式在践行“微服务”。因此，基于“求同存异”的原则，詹姆斯·刘易斯的同事、著名的马丁·福勒采用归纳法来解决这个问题：他认为“定义”是一些“共同特征”。MartinFowler继续沿用了JamesLewis对这一系列实践的命名，并对其进行了修改，成为一个单独的术语——微服务。因此，他将微服务总结为以下九大特征：通过服务组件化围绕业务能力进行组织是一个产品而不是一个项目智能端点和哑管道去中心化治理去中心化数据管理基础架构自动化设计失败进化设计我们可以设计它可以是由此可见，MartinFowler试图泛化JamesLewis的微服务定义，使其不仅可以用于不同的语言架构和技术栈。它还可以兼顾敏捷、DevOps等其他技术，成为架构上“最佳实践”的集合。但是，这样一组实践，本质上并没有太多的创新，只是将很多我们熟知的架构和设计原则，与当前的技术栈进行了整体的结合和应用。恰逢一系列互联网公司在经历了早期采用者（EarlyAdopter）井喷的结果后，成功带来的新实践（持续交付，DevOps）和新技术（Docker）。这种对最佳实践的集中响应当然受到了技术人员的称赞。然而，这个定义对于那些试图采用“微服务架构”的人来说是一个很高的门槛。如果这样概括9个特征就是“微服务架构”的定义。那么，为了满足以上9个定义，改造需要付出很大的努力，已经超出了技术升级和企业IT部门的范畴。此外，即使我们知道其中每个特征的好处，也很难拿出案例和数据来支持满足这9个特征的转型好处。避免了这9个特性的概念正交性，即使这9个特性可以从现有的结果中回答“微服务是什么（What）”，但并没有给出“为什么（Why）应该满足这些特性”和“如何（How）”同时满足这些特征”。自己挖的坑自己填不上，就教别人填。三、SamNewman版微服务的两大特点和7大原则。同样作为MartinFowler的同事，SamNewman在他的著作《BuildingMicroservice》（中文翻译为《微服务设计》）第一章中重新回答了“WhatisMicroserviceArchitecture”，回答了“WhyMicroserviceArchitecture”的问题。SamNewman是这样定义微服务的（《微服务设计》译）：微服务是协同工作的小型自治服务。SamNewman自述对微服务的定义更为简单，包括“小”和“自治”两个特征。除了继承JamesLewis对微服务应该多小的描述（当然大小是个人主观判断），康威定律还创造性地用于约束微服务的大小，即“是否能匹配团队structure》：如果你的团队难以维护单一服务，需要在保持团队规模不变的同时轻松维护维护工作，那么这个服务就需要继续拆分。而“自治”则将MartinFowler定义的微服务的九大特征中的“去中心化”、“独立性”、“松散耦合”等词小心翼翼地统一了起来。并进一步说明“一个微服务是一个独立的实体”。而从外部，也就是黑盒的角度来看每一个满足“自治”的个体微服务的特性，即：可以独立部署。通过网络进行通信。对消费者透明。保持尽可能低的耦合并使其自治。此外，他还采用了更为简单的“金科玉律”来判断时期的“自治”。也就是说，可以在不影响任何其他服务的情况下修改和部署服务。如果答案是否定的，那么你的微服务还不够“自治”。从SamNewman的定义中，我们可以推导出关于“微服务”的几个基本事实：微服务架构是一种分布式系统架构。微服务是微服务架构的基本单元。网络隔离是一种“必要”的解耦手段。微服务的业务功能在概念上是完整的，符合用户角度的“独立”认知。简而言之，以上两个特性的表达主要是将微服务从逻辑架构和部署架构上看成是一个正交的原子功能单元。为此，您需要将整个应用系统正确建模到这个级别，您需要参考许多内部和外部因素。此外，为了实现“小”和“自治”的目标，SamNewman还总结了7条在实施时要结合具体实践的原则，即：围绕业务概念建模接受自动化文化隐藏内部实施细节让一切都是去中心化，可以独立部署。隔离和失败是很容易观察到的。可以看出，SamNewman用更具体的术语重新描述了MartinFowler的九大特征，逻辑上处理了MartinFowler的微服务九大特征中概念的重复。和模棱两可的部分，使它更简单、更清晰、更可操作。例如，将“去中心化数据管理”和“去中心化治理”合并为“去中心化一切”等。更重要的是，SamNewman提出了采用微服务技术的主要好处，并告诉我们“为什么要使用微服务”：Technologyheterogeneity:useamore合适的技术栈，灵活处理局部问题。弹性：这里的“弹性”是弹性工程的概念，意思是局部失效会被隔离，整体不会失效。扩展：可以根据系统的某些组件进行按需扩展。极简部署：这里的极简部署不是指部署拓扑，而是通过持续的小批量小规模部署来降低整体失败的风险。与组织结构相匹配：微服务架构可以将组织的团队转化为合适的规模，并采用透明的体系进行规范和复制。避免团队数量的增长带来更多的管理，使组织熵增加。可组合性：由于微服务之间没有依赖关系，可以根据用户界面的情况灵活调整和复用，避免对单个应用进行大规模的整体调整。可替代性的优化：由于更大的独立性和风险和领域的隔离。因此，扔掉一个微服务并重写它的成本并不会变得很便宜。4.ChrisRichardson的《微服务架构模式》2017年，ChrisRichardson使用Microservices.io域名开始推广他的微服务理念。他这样定义微服务：微服务——也称为微服务架构——是一种架构风格，它将应用程序构建为松耦合服务的集合，这些服务实现了业务能力。微服务架构支持持续的大型交付/部署、复杂的应用程序。它还使组织能够发展其技术堆栈。从中文翻译过来，大致思路是这样的：microservices，即微服务架构。它是一种架构风格，用于将应用程序构建为实现业务功能的松散耦合服务的集合。微服务架构支持大型复杂应用程序的持续交付和持续部署。它使组织能够发展他们的技术堆栈。ChrisRichardson采用简单的架构定义和准确的目标定义相结合的方式来定义“微服务架构”：一方面，它简单地将微服务架构定义为实现业务功能的松耦合服务的集合，另一方面一方面，这种松耦合系统的效果受到非常具体的目标和结果（持续交付/持续集成）的限制：组织可以发展自己的技术堆栈。ChrisRichardson将“单体架构”和“微服务架构”视为两种架构模式。并且在相同的语境下，对比两者的优缺点。更重要的是，ChrisRichardson使用AFKscalingcube拆分微服务来回答“如何做微服务”的问题。值得注意的是，ChrisRichardson所举的例子，虽然是在同一语境下，但由于特点不同，没有可比性。因此，他采用了在《模式：单体架构》的基础上描述其局限性的方法，引出了《模式：微服务架构》。严格来说，ChrisRichardson的“单体架构模式”是现状的一个例子，并没有给出其特征和方法的描述，因此不能称为模式。“微服务架构模式”是一系列模式的总和，如下图所示：从这个角度看，ChrisRichardson的这些模式并没有突破SamNewman在《微服务设计》中总结的实践。但是相比我们所知道的微服务的优势。ChrisRichardson也列举了微服务的劣势：开发者的IDE相比单体应用架构，对于分布式系统的在线开发和调试并不友好。测试更加困难。开发人员必须实现跨服务的通信机制。不使用分布式事务很难跨服务构建业务。需要跨团队的协调。部署比较复杂。更多的内存消耗。对于Java应用，独立部署意味着JVM的内存管理不能共享。与之前的微服务定义相比，ChrisRichardson的微服务体系是比较完整的，而不仅仅是总结和列举实践。ChrisRichardson的《微服务架构模式》不仅回答了“Whatis(What)Microservice”，还回答了“Why(Why)useMicroservice”、“When(When)UseMicroservice”、“Whatscenario(Where)”和“How（如何）实施微服务”。ChrisRichardson还编写了一套微服务指南，可以在此处查看。比“什么是微服务”更重要的东西本文总结了微服务的4种常见定义。但比这些定义更重要的是你为什么要使用微服务？您希望从微服务中获得哪些好处？您了解追求这些好处的成本吗？不先弄清楚这些问题，就无法理解微服务。架构或技术带来的风险和成本。一味地采用所谓的微服务可能不会带来理想的结果。但是，在讨论这些问题之前，先坐下来统一对微服务的理解，会提高我们讨论微服务和实践微服务的效率。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
