学习笔记-架构的演进之微服务-2月day05

july7may

于 2023-02-12 00:16:20 发布

阅读量134

点赞数

文章标签：架构微服务

本文链接：https://blog.csdn.net/sinat_22180095/article/details/128990708

版权

微服务是一种基于业务能力构建、分散治理、独立自治组件的架构风格，强调产品化思维、数据去中心化、轻量级通讯和容错性设计。通过演进式设计和基础设施自动化，实现服务的持续改进和高效运维。微服务架构降低了单体架构的复杂性，但也对架构决策提出了更高要求。

摘要由CSDN通过智能技术生成

引言

微服务这个名词很早就出现了，Peter Rodgers 博士在 2005 年的云计算博览会（Web Services Edge 2005）上提出了 “Micro-Web-Service”，指的是一种专注于单一职责的、与语言无关的、细粒度的 Web 服务（Granular Web Services）。而这一阶段的微服务，是作为 SOA （Service-Oriented Architecture）的一种轻量化的补救方案而被提出来的。

2012 年，在“33rd Degree Conference”大会上，Thoughtworks 首席咨询师 James Lewis 做了题为《Microservices - Java, the Unix Way》的主题演讲。其中，他提到了单一服务职责、康威定律、自动扩展、领域驱动设计等原则，号召大家应该重拾 Unix 的设计哲学（As Well Behaved Unix Services）。

微服务真正崛起是在 2014 年，Martin Fowler 和 James Lewis 的文章“Microservices: a definition of this new architectural term”中，第一次真正丰富的、广为人知的和可操作的阐述了微服务指南。可以说，这篇文章是微服务的真正起源。文章定义了现代微服务的概念：微服务是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。

微服务的核心业务与技术特征

第一，围绕业务能力构建（Organized around Business Capabilities）

围绕业务能力构建，即康威定律，有怎样的结构、规模和能力的团队，就会产生出对应结构、规模、能力的产品。

如果本应该归属同一个产品内的功能，被划分在了不同的团队当中，那就必然会产生大量的跨团队沟通协作，而跨越团队边界，无论是在管理、沟通，还是在工作安排上，都会产生更高的成本。高效的团队，自然会针对这个情况进行改进，而当团队和产品磨合调节稳定了之后，就会拥有一致的结构。

（这对架构设计要求很高呀！）

第二，分散治理（Decentralized Governance）

微服务对应的开发团队，有着直接对服务运行质量负责的责任，也应该有着不受外界干预，掌控服务各个方面的权力，可以选择与其他服务异构的技术来实现自己的服务。

微服务更加强调的是，在确实有必要进行技术异构的时候，一个开发团队应该能有选择“不统一”的权利。比如说，我们不应该强迫用 Node.js 去开发报表页面；要做人工智能计算的时候，也可以选择用 Python，等等。

第三，通过服务来实现独立自治的组件（Componentization via Services）

这里强调要通过“服务”（Service）而不是“类库”（Library）来构建组件，是因为类库是在编译期静态链接到程序中的，会通过本地调用来提供功能，而服务是进程外组件，它是通过远程调用来提供功能的。尽管远程服务有更高昂的调用成本，但这是为组件带来隔离与自治能力的必要代价。

第四，产品化思维（Products not Projects）

产品化思维的意思就是，我们要避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程。

开发团队应该为软件产品的整个生命周期负责。开发者不仅应该知道软件是如何开发的，还应该知道它会如何运作、用户如何反馈，乃至售后支持工作是怎样进行的。这里服务的用户，不一定是最终用户，也可能是消费这个服务的另外一个服务。

以前在单体的架构模式下，程序的规模决定了我们无法让全部的开发人员，都关注到一个完整的产品，在组织中会有开发、运维、支持等细致分工的成员，他们只关注于自己的一块工作。但在微服务下，我们可以让团队中的每一位成员，都具有产品化思维。因为在“2 Pizza Teams”的团队规模下，每一个人都了解全过程是完全有可能实现的。

（微服务时代的全栈工程师）

第五，数据去中心化（Decentralized Data Management）

微服务这种架构模式也明确地提倡，数据应该按领域来分散管理、更新、维护和存储。

在单体服务中，通常一个系统的各个功能模块会使用同一个数据库，虽然这种中心化的存储确实天生就更容易避免一致性的问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。

另外，尽管在分布式中，我们要想处理好一致性的问题也很困难，很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻，一致性问题这些必要的代价是值得付出的。

第六，轻量级通讯机制（Smart Endpoints and Dumb Pipes）

这个弱管道（Dumb Pipes）机制，是在直接反对 ESB、BPM 和 SOAP 等复杂的通讯机制。ESB 可以处理消息的编码加工、业务规则转换等；BPM 可以集中编排企业的业务服务；SOAP 有几十个 WS-* 协议族在处理事务、一致性、认证授权等一系列工作。这些构筑在通讯管道上的功能，也许在某个系统中的确有一部分服务是需要的，但对于另外更多的服务来说是强加进来的负担。

如果服务需要上面的某一种功能或能力，那就应该在服务自己的 Endpoint（端点）上解决，而不是在通讯管道上一揽子处理。微服务提倡的是类似于经典 Unix 过滤器那样，简单直接的通讯方式。比如说，RESTful 风格的通讯，在微服务中就是比较适合的。

第七，容错性设计（Design for Failure）

容错性设计，是指软件架构不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实。

这个技术特征要求，在微服务的设计中，有自动的机制能够对其依赖的服务进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。所以“断路器”这类设施，对实际生产环境的微服务来说，并不是可选的外围组件，而是一个必须的支撑点。如果没有容错性的设计，系统很容易就会因为一两个服务的崩溃带来的雪崩效应而被淹没。

可靠系统完全可以由会出错的服务来组成，这是微服务最大的价值所在。

第八，演进式设计（Evolutionary Design）

容错性设计承认服务会出错，而演进式设计则是承认服务会被报废淘汰。一个良好设计的服务，应该是能够报废的，而不是期望得到长久的发展。

如果一个系统中出现不可更改、无可替代的服务，这并不能说明这个服务有多么重要，反而是系统设计上脆弱的表现。微服务带来的独立、自治，也是在反对这种脆弱性。

第九，基础设施自动化（Infrastructure Automation）

基础设施自动化，如 CI/CD 的长足发展，大大降低了构建、发布、运维工作的复杂性。
由于微服务架构下，运维的服务数量比起单体架构来说，要有数量级的增长，所以使用微服务的团队，会更加依赖于基础设施的自动化。毕竟，人工是无法运维成百上千，乃至成千上万级别的服务的。

总结

从以上对微服务的定义和特征的解读当中，可以明显地感觉到，微服务追求的是更加自由的架构风格，它摒弃了 SOA 中几乎所有可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。可是，如果没有了统一的规范和约束，以前 SOA 解决的那些分布式服务的问题，不又都重新出现了吗？
的确，服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理等问题，在微服务中，都不再会有统一的解决方案。

在微服务时代中，软件研发本身的复杂度应该说是有所降低，一个简单服务，并不见得就会同时面临分布式中所有的问题，也就没有必要背上 SOA 那百宝袋般沉重的技术包袱。微服务架构下，我们需要解决什么问题，就引入什么工具；团队熟悉什么技术，就使用什么框架。

虽然微服务架构对普通的服务开发人员十分友好，但是对于架构者来说却是满满的恶意，因为它对架构能力的要求可以说是史无前例。要知道，技术架构者的第一职责就是做决策权衡，有利有弊才需要决策，有取有舍才需要权衡。如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中的利弊，也就不可避免地会陷入选择困难症的困境之中。