你知道微服务架构深度解析：微服务的主要特性有哪些吗？

微服务主要特性

粒度更细的服务

微服务架构相比SOA分布式架构强调按业务边界做细粒度的服务拆分。SOA架构使用粗粒度的服务模式来封装业务和技术能力，减少服务交互，但同时带来了业务耦合的复杂性。而微服务架构本质上是一个做减法的架构，将规模庞大的单体系统进行服务拆分，每个细粒度服务的功能和职责单一。当然，服务的粒度并不是拆得越细越好，如果拆分不当，还会造成服务频繁地跨网络操作，增加系统的整体复杂性。

首先，微服务粒度的划分要求工程师充分理解和洞察业务领域的边界，保证你所拆分的服务是自包含的。所谓“自包含”就是说你的服务是可以独立部署、独立演进的，你的服务可以自主地完成某个特定的、单一的功能。

其次，细粒度服务应该同时具备高内聚和低耦合两个特征。高内聚要求将系统中相关的元素和行为聚集在一起，把不相关的元素和行为放在别处；低耦合是指降低微服务之间的相互依赖程度和相互作用关系，如果服务之间存在紧密联系，说明它们的耦合度比较高，最好不要做拆分操作，而应该做聚合操作，这样可以使信息的传递和协作比拆分成独立的服务更加简单可控。

另外，细粒度服务应该尽量做到独立。这一特性也适用于单一职责原则： SRP （ Single Responsibility Principle ），该原则由Robert C.Martin提出。从面向对象设计的角度看，所谓职责是指一个类（Class）变化的原因。如果一个类有多个改变动机，那么这个类就具有多个职责，而单一职责原则就是指一个类或者模块应该有且只有一个改变原因。

下面总结一下粒度更细的服务带来的好处：

● 粒度更细的服务使每一个服务专注做好一件事情。每个服务完成一个单一任务，在功能不变的情况下，应用被拆分为多个可管理的服务，很好地解决了系统的复杂性问题。

● 粒度更细的服务有助于新人对工程的学习。对于一个大型的、生命周期比较长的项目，人员的流动和组织变化是经常发生的事情，而庞大的单体架构容易使模块之间相互耦合，功能界限模糊，同时增加了新人的学习成本。

● 粒度更细的服务有利于部署。对于大型单体项目，模块之间往往存在紧密的代码耦合，一个子模块的编译错误往往会导致整个应用无法构建成功，而细粒度的服务可以通过独立工程解决“牵一发而动全身”的问题。

● 粒度更细的服务具备更好的复用性。在软件领域，我们一直提倡使用复用的方式构建系统，粒度更细的服务通过独立的部署，通过声明语言无关、平台无关的标准接口（REST API、gRPC）对外暴露服务，实现了积木式的架构搭建模式，提高了软件整体的开发效率。

围绕业务划分团队

传统的IT企业习惯根据人员掌握的技能来划分组织。例如，熟悉前端的同事，都集中在一个前端开发团队；熟悉数据库的同事，一般都会集中在DBA（Database Administrator，数据库管理员）团队；熟悉测试的同事，专门成立一个测试团队专职做测试工作。我们习惯于将这样的团队称为“职能型组织”，它的优势是资源集中，有利于同一职能内部的专业人士交流和经验积累。

然而，职能型组织最大的问题是团队之间不容易协调利益冲突，容易形成部门墙或者叫部门壁垒。当职能部门有多个项目同时进行时，就会产生资源失衡问题，不利于各职能部门之间的沟通交流和团结协作。业务的需求变化如果牵涉多个职能型组织所负责的模块协作联调，往往会出现项目排期问题、优先级问题，对于跨地域、跨国家的组织，还会出现时差问题、沟通及文化差异问题，这个时候反而增加了团队之间的沟通和协调成本，降低了开发效率。

微服务架构更加提倡以业务为中心，强调围绕业务领域来划分团队。团队由具备不同能力象限的人员组成，而这样的全功能型团队相比职能型团队可以防止人员之间的互相扯皮、互相指责的问题。同一个团队围绕业务领域沟通效率更高，团队合作更加积极主动，有更强的主人翁意识（Ownership）。从技术的维度看，微服务架构倾向于在指定范围的“业务界限上下文”中定义标准规范的交互方式，这样能够保证业务接口（API）更加稳定，在后续服务的迭代升级过程中具备更好的业务兼容性和可演进性。

综上所述，在围绕业务构建微服务架构的时候，解决的一个本质问题就是人员分工的问题，正如康威定律所说，任何组织所设计的系统、所交付的软件产品方案在结构上都应该与该组织的沟通结构和组织方式保持一致。下面是组织结构演进示意图。

技术多样性

微服务架构不限定提供服务方所使用的技术栈和技术选型。微服务架构倾向于服务之间使用标准的轻量级的通信协议（HTTP）完成服务的集成和通信。例如，对于性能要求比较高、对网络通信效率比较关注的服务，可以使用C++语言构建；对于文本分析性的业务，可以采用Python脚本语言；而对于企业应用级的Web项目，使用Java语言开发比较合适。可见，每一种语言和技术都有其“擅长”的场景和适合解决的问题。

微服务架构提倡数据存储的多样性和独立性。不同的数据存储引擎有各自擅长处理的业务类型数据。对于公司的核心业务即OLTP（OnLine Transaction Processing，联机事务处理）业务，可能会采用MySQL这样的关系型数据库。关系型数据库的特点是遵循ACID原则，对事务的一致性有更好的支持，通过标准的SQL语言就可以方便地实现结构化数据的查询和更新。

在 NoSQL 数据库阵营中，对于日志数据，可以存放在Elasticsearch这样的LSM树数据结构存储引擎中，适合日志搜索、查询操作；对于分布式系统之间的共享数据，采用Redis这样的内存引擎，在读写效率、高并发性能上有更大的优势；如果是文档型数据，使用MongoDB这样的文档存储引擎更加高效便利。下面是采用不同编程语言和技术栈配合不同的数据存储类型的技术多样式示意图。

微服务架构提倡在技术多样性的场景中，选择最适合的技术栈。

微服务通过使用标准的API接口对外暴露服务，给尝试新技术提供了更加友好的架构支持。

然而，很多公司也推崇使用统一的编程语言和标准化的技术栈。

统一技术栈的优势也是明显的，首先它会带来开发效率的提升；单一技术栈的维护成本相对较低；新加入的开发人员也能够尽快适应统一的编程语言和架构风格；项目的风险相对比多技术栈有更好的可控性。

即便如此，我们说微服务架构还是向着异构化、技术多样性的趋势在发展，因为只有保持技术的多样性，才能保证技术生态的生命力。对于技术栈和技术选型来说，架构师需要一个Trade-off（权衡利弊）的过程。

去中心化

大型企业在集成异构系统和完成进程之间的通信时，一种传统的架构模式就是使用ESB消息总线技术，它可以完成信息路由、业务规则编排、协议转化等功能。虽然，ESB架构改变了传统软件的架构模式，消除了不同应用之间的技术差异，协调了不同应用服务的协作运行方式，实现了服务之间的集成和整合，但是，ESB架构倾向于使用集中式的架构管理模式，它本质上是一种中心化的架构。我们将这种企业服务总线或服务编配系统的方案称为“智能管道和哑终端”模式，它会导致业务逻辑的中心化和哑服务问题。

“哑终端”（Dumb Endpoint）会导致ESB消息总线过度复杂，这种中央式的架构模式存在天然的技术与业务耦合问题。业务编排和业务消息转化能力与业务功能全部集中在单一逻辑控制单元中，它并没有做很好的业务封装，而是将业务逻辑的复杂性全部传递到了消息总线中。同时，随着服务规模的扩大，中心化架构的可扩展性会成为一个极大的障碍。业务中的职责边界不清和ESB中心化的问题还会暴露性能问题，成为系统的瓶颈。

微服务架构摒弃了ESB的设计理念，在微服务架构中，服务使用智能端点（Smart Endpoint）模式。智能端点强调所有的业务逻辑应该自包含在业务内部的处理逻辑单元中，它可以确保在服务限界内服务的内聚性，而服务之间的通信应该尽量轻量化和简单化。同时，微服务使用哑管道（Dumb Pipe）通信机制，将业务无侵入的公共组件抽象出来，封装在通用的消息基础设施中（API网关、消息中间件等）。

我们把微服务架构这样的设计理念称为“去中心化”。微服务架构倾向于服务之间订立标准化的服务契约，目标是通过明确清晰的服务边界和服务契约机制让服务可以各自独立迭代和演进。

为了最大化微服务能带来的自治性，我们需要给拥有服务的团队委派决策和控制权。去中心化管治的最高境界就是亚马逊所宣扬的“构建并运行它”的理念，团队对构建的软件的方方面面负责。

自动化运维

微服务架构的采用也引入了很多复杂性，关键问题是我们不得不管理大量的服务。微服务增大了运维负担；有更多的东西需要部署，有更多的地方需要监控，错误自然也成倍增加。而解决这些问题的一个关键方法就是拥抱“自动化文化”。前期花费一定的成本，构建支持微服务的工具是很有意义的，比如，自动化测试保证开发迭代中的代码质量，使用自动化发布工具将微服务部署到各个环境，使用配置文件来明确不同环境间的差异，创建自定义镜像来加快部署，创建全自动化的不可变服务器。

自动化一直是软件系统运维的最佳实践，也是微服务架构强调的重要特性。云技术使得底层基础设施及运行在之上的组件自动化变得非常简单。尽管前期投入通常会更高，但从中长期来看，无论是人力运维成本，还是在系统的弹性和性能方面，几乎总能获得更多的回报。自动化可以比人更快地修复、扩展和部署系统。

自动化贯穿软件生命周期的整个过程，在持续集成领域，我们经常使用Jenkins等工具自动构建、测试和部署微服务软件包。微服务不仅应该自动化部署，还应该努力实现金丝雀测试和回滚等过程的自动化。

除非系统负载几乎从未发生变化，否则应该根据负载的增加对微服务进行自动扩展，并根据负载的持续下降进行自动收缩。通过扩展可以确保服务仍然可用，通过按比例收缩可以降低成本。

随着微服务及云原生架构的大规模推广和使用，部署和运维的复杂度会逐渐从业务端下沉到以Kubernetes为代表的基础设施PaaS平台，利用云和微服务架构，我们可以更加快速地部署和交付我们的服务，围绕快速交付的基础设施建设是微服务架构规模化发展的首要任务。

快速演进

软件的固有特性随着时间的推移会变得越来越难以改变，软件的组成部分会因为各种各样的问题变得脆弱，难以操作。软件和现实世界一样，当人类的需求和环境供给达到平衡时，世界是美好的，然而当这种平衡因为虫害或者气候变化被打破时，人类需要向生态中引入变化，重新建立平衡。对于软件系统，同样存在这种动态的平衡，我们需要提早对系统进行规划和设计。

尽管很多人喜欢在一个理想的环境下来讨论架构，然而，对于庞大复杂的单体架构，很多因素可能促使我们将混乱引入系统工程：业务需求的快速变化、工作任务的优先级冲突、有限的人力资源和预算、软件工程师水平的参差不齐、缺乏规范的开发流程和部署方式。另外，如果是遗留系统，还会存在代码版本混乱、冗余的代码逻辑等技术债务。这种技术包袱总会带来灾难性的后果。通常，业务人员往往不想放弃还在工作的系统，而开发人员，面对单体系统的腐化，只能通过不断地堆叠功能完成任务。不停地做加法，架构成为塞满各种功能和修复逻辑的庞然大物，最终产生破窗效应。而这种架构上的缺陷也将持续加重我们的技术债务，业务人员要么忍受这样糟糕的设计、不断地妥协，要么丢弃已有系统，推倒重来，这样的做法对于资源有限的团队和公司来说，显然是难以承受的。

微服务架构强调在项目早期将软件分成若干个阶段及不同的模块，从时间、业务维度及架构维度上做水平和垂直化的分解。微服务构建的首要任务就是理解业务的问题域，好的架构师会充分考虑业务领域的内聚性，降低业务之间的耦合，寻求两者的平衡，并将架构的可扩展性作为重要的设计考量因素。微服务架构的一个特征就是面向架构演进，微服务架构的目标正是通过业务领域的边界划分、通过服务的隔离来分解问题，逐个击破，因此微服务架构天然具备了可演进性。