爱酷升级为梦饷集团，全力打造电商新基础设施
06-17
微服务架构（Microservices） 微服务是一种通过多个小型服务组合来构建单个应用程序的架构风格。这些服务是围绕业务能力而不是特定的技术标准构建的。
每个服务可以使用不同的编程语言、不同的数据存储技术，并运行在不同的进程中。服务采用轻量级通信机制和自动化部署机制来实现通信和运维。
微服务的前世今生 “微服务”这一技术术语于 2008 年首次提出，由 Peter Rodgers 博士在年度云计算博览会（Web Services Edge）上首次使用。当时被称为“Micro-Web-Service”，指的是一种独立于语言、专注于单一职责的细粒度 Web 服务（Granular Web Services）。
“微服务”一词并不是 Peter Rodgers 直接凭空创造的概念。新生的微服务可以说是上述《演进中的架构之SOA时代》的产物，就像Spring和Hibernate在EJB推广过程中诞生一样。
现阶段的微服务被提议作为 SOA 的轻量级补救措施。直到今天，英文版维基百科仍然将微服务定义为 SOA 的变体形式。
因此，微服务初期涉及到SOA、Web Service等概念是完全可以理解的，但现在我们来看一下。 ，维基百科对微服务的定义已经相当过时了。
什么是微服务微服务是一种软件开发技术——面向服务的架构（SOA）结构风格的一种变体。 — 维基百科，微服务 微服务的概念提出后，近 10 年并未受到太多关注。
如果只是现有SOA架构的拼凑，确实很难激起技术人员更多的热情。然而，这10年，微服务本身也在思考和变革。
在波兰克拉科夫举行的“33rd Degree Conference”上，Thoughtworks 首席顾问 James Lewis 做了题为“《Microservices - Java, the Unix Way》”的主题演讲，其中提到了单一服务责任、康威定律、自动扩展、领域驱动设计和其他原则，但没有提到SOA。相反，主张重拾Unix的设计哲学（As Well Behaved Unix Services）。
这似乎呼应了作者上一节提到的“初心与自省”。微服务迫不及待地想摆脱SOA的依赖，成为一种独立的架构风格。
或许，他们也将成为SOA的革命者。微服务真正兴起是在 2007 年。
相信本文的大多数读者都是从 Martin Fowler 和 James Lewis 合写的文章中第一次了解微服务的。这并不意味着您必须阅读本文。
，或者准确地说，你今天所认识的“微服务”就是本文提出的“微服务”。本文定义了现代微服务的概念：“微服务是一种通过小型服务组合构建单个应用程序的架构风格。
这些服务是围绕业务能力而不是特定的技术标准构建的。各个服务可以采用不同的编程语言和不同的数据存储技术运行在不同的进程中。
服务采用轻量级通信机制和自动化部署机制来实现通信和运维。”此外，文章还列出了微服务的九大核心业务和技术特征。
作者一一列举，解读如下： 围绕业务能力组织，这里再次强调了康威定律的重要性，团队有什么样的结构、规模、能力，就会生产出与结构、规模、能力相对应的产品，这个结论不是某个团队或公司遇到的巧合，而是。这是进化的必然结果，如果将属于同一个产品的功能划分到不同的团队，必然会出现大量的跨团队沟通和协作，在管理、沟通和协作方面都会产生更高的成本。
工作安排有了高效的团队，自然就会有所改进。当团队和产品调整稳定后，团队和产品就会有一个一致的结构。
去中心化治理意味着“谁拥有孩子，谁就负责”。服务对应的开发团队对服务运行的质量直接负责，也应该有能力掌控服务的各个环节，不受外界干扰。
权力，例如选择与其他服务异构的技术来实现自己的服务。在实际操作中，这有些宽松。
大多数公司不会将 Java 用于一项服务，将 Python 用于另一项服务，而将 Golang 用于下一项服务。他们通常会统一主流语言，甚至有统一的技术栈。
或专有技术平台。微服务并不提倡也不反对这种“统一”。
只要负责提供和维护基础技术栈的团队意识到被各方依赖，并做好“经常被凌晨3点闹钟叫醒”的心理准备。好的。
微服务更强调的是，当确实需要技术异构时，你应该有选择“非统一”的权利。例如，不应该强迫 Node.js 来开发报告页面。
做人工智能计算的时候，应该可以选择Python等等。通过服务实现组件的独立自治（Componentization via Services），之所以强调通过“服务”（Service）而不是“类库”（Library）构建组件，是指类库在编译时静态链接到程序中。
，通过本地调用提供功能，而服务是通过远程调用提供功能的进程外组件。在上一篇文章中，我们分析过，虽然远程服务的调用成本较高，但这却是为组件带来隔离和自治的必要代价。
产品思维（产品而不是项目）避免将软件开发视为完成某种功能，而是将其视为持续改进和改进的过程。例如，运维不应该被视为运维团队的业务，而开发应该被视为开发团队的业务。
团队应对软件产品的整个生命周期负责。开发人员不仅要知道如何开发软件，还要知道如何开发软件。
它是如何运作的，用户如何反馈，甚至售后支持工作如何进行。这里服务的用户不一定是最终用户，也可能是消费这个服务的另一个服务。
过去，单体架构下，程序的规模使得所有人员无法专注于完整的产品。开发、运维、支持等分工细化的组织成员只专注于自己的工作。
但在微服务下，希望团队中的每个人都有产品思维是可取的。数据去中心化（Decentralized Data Management），微服务明确主张数据应该按领域去中心化管理、更新、维护和存储。
在单个服务中，系统的各个功能模块通常使用相同的数据库。诚然，中心化存储本质上更容易避免一致性问题，但同一数据实体的抽象形式从不同服务的角度来看往往是不同的。
例如，书店应用中的书籍，销售字段重点关注价格，仓储字段重点关注库存数量，产品展示字段重点关注书籍的介绍信息。如果用作中心化存储，所有这些字段都必须修改并映射到同一个实体，这使得不同的服务可能会相互影响并失去独立性。
虽然分布式系统中的一致性问题很难处理，很多时候使用传统的事务处理也无法保证，但这是两害相权取其轻，并且有一些必要的成本是值得付出的。智能端点和哑管道（Smart Endpoints and Dumb Pipes）和哑管道几乎从名字上就直接与 SOAP 和 ESB 的复杂通信机制相对立。
ESB可以处理消息编码和处理、业务规则转换等； BPM可以集中编排企业业务服务； SOAP 拥有数十个 WS-* 协议族，用于处理事务、一致性、身份验证和授权等一系列任务。这些建立在通信管道上的功能可能是某个系统的一部分。
服务是必要的，但额外的服务是一种强加的负担。如果一项服务需要上述功能或能力之一，则应在服务自己的 Endpoint 上解决，而不是全部打包在通信通道上。
微服务提倡一种类似于经典Unix过滤器的简单直接的通信方法。 RESTful风格的通信是微服务中更合适的选择。
容错设计（Design for Failure）不再追求服务永恒稳定的虚幻追求，而是接受服务总会出错的现实。它要求在微服务的设计中，有一种自动机制来快速检测其所依赖的服务的故障。
，当错误继续存在时进行隔离，并在服务恢复时重新连接。因此，“断路器”等设施并不是微服务在实际生产环境中可选的外围组件，而是必要的支撑点。
如果没有容错设计，系统很容易因为一两个错误而损坏。服务崩溃造成的雪崩效应是巨大的。
可靠的系统可以完全由可能失败的服务组成。这就是微服务最大的价值，也是这份开源文档“The Fenix Project”的标题的含义。
进化设计（Evolutionary Design），容错设计承认服务会出错，进化设计承认服务会报废、淘汰。一个设计好的服务应该是可以废弃的，而不是指望长期发展。
如果一个系统中有一个不可替代、不可替代的服务，并不是说这个服务有多重要，而是它是一个系统。设计上脆弱性的一种表现，微服务带来的独立性和自治性也是对抗这种脆弱性的表现。
基础设施自动化：基础设施自动化，如CI/CD的快速发展，显着降低了构建、发布、运维工作的复杂度。由于运维服务数量相比单体架构增加了一个数量级，因此使用微服务的团队更加依赖于基础设施自动化。
不可能手动操作和维护数百、数千甚至数千个服务。 《Microservices》文章中对微服务特性的描述还是比较具体的。
除了定义什么是微服务之外，本文还特别说明了微服务不是什么——微服务不是SOA的变体或衍生品，应该明确说明它与SOA划清了界限，不再贴上任何SOA标签。这样，微服务概念才算真正完整、独立、具体的架构风格，为其未来几年在技术舞台上如明星般闪耀奠定了理论基础。
微服务和 SOA SOA 的这种常见表现形式导致一些微服务倡导者完全拒绝 SOA 标签，尽管其他人认为微服务是 SOA 的一种形式，也许面向服务做得正确。不管怎样，SOA 意味着如此不同的事物这一事实意味着它是有价值的。
有一个更清晰地定义这种架构风格的术语与 SOA 具有一致的表达方式，这使得微服务支持者更渴望拒绝被贴上 SOA 的标签，尽管有些人坚持认为微服务是 SOA 的一部分。一种变体，也许从面向服务的角度来看，但无论如何，SOA和微服务是两个不同的东西，正因为如此，使用不同的名称来简洁地定义这种架构风格就变得更加必要。
——Martin Fowler / James Lewis，微服务 从上面微服务的定义和特点，可以明显感觉到微服务追求更加自由的架构风格，抛弃了 SOA 中几乎所有可以抛弃的约束和规定，提倡取代“规范”标准”与“实用标准”。但是，如果没有统一的规范和约束，以前SOA解决的分布式服务问题岂不是会突然全部重现？确实，微服务中的这些问题，例如服务注册发现、跟踪管理、负载均衡、故障隔离、认证授权、伸缩、传输通信、事务处理等，都没有统一的解决方案，即使只讨论Java。
将在范围内使用的微服务，仅针对服务之间的通信问题，可以包含在候选解决方案列表中：RMI（Sun/Oracle）、Thrift（Facebook）、gRPC（Google）、Motan2（新浪）、Finagle (Twitter)、Arvo (Hadoop)、JSON-RPC、REST 等。如果您发现只有一项服务有问题，您可以选择：Eureka (Netflix)、Consul (HashiCorp)、Zookeeper (Apache)、Etcd (CoreOS) ）、CoreDNS（CNCF）等。
其他领域的情况与此类似。总之，完全是八仙渡海，各显神通的局面。
微服务带来的自由是一把双刃剑。当软件架构师拿起这把剑时，其锋芒指向 SOA 制定的复杂技术标准，并夺回了选择权。
与此同时，另一边，也向他反射出一道寒光。微服务时代，软件开发本身的复杂度应该说是降低了。
一个简单的服务不一定要同时面对分发中的所有问题，也没有必要背着SOA沉重的宝袋。技术包袱。
需要解决什么问题就需要引入哪些工具；团队熟悉的任何技术都应使用哪些框架。此外，像Spring Cloud这样的胶水式全家桶工具集，通过一致的接口、声明和配置，进一步屏蔽了特定工具和框架衍生的复杂性，降低了不同工具和框架之间的切换成本。
，因此，作为一个普通的服务开发者，作为一个“螺丝钉”程序员，微服务架构是友好的。然而微服务对架构师充满了恶意，对架构能力的要求提高到了前所未有的水平。
作者在这篇文档的很多地方都反复强调，技术架构师的首要职责就是做出决策和权衡，这是有益的、有益的。只有在存在不利的情况下才需要做出决定，并且需要权衡利弊。
如果架构师自身的知识不足以涵盖决策所需的内容，并且不清楚利弊，那么他可能不可避免地会陷入选择困难的困境。微服务时代充满了自由，也充满了令人困惑的选择。
软件架构不会止步于自由。微服务并不是架构探索的终点。
如果有下一个时代，我希望信息系统也能拥有微服务的自由，围绕业务能力构建自己的服务，而不受技术规范的约束。但同时，也不必以自己承担解决分布式问题的责任为代价。
不管有什么好处和坏处！只有孩子才会做多项选择题，但所有成年人都会做！关于作者 周志明是腾讯云最有价值专家（TVP），Java技术、机器学习和企业级开发技术方面的专家。现任远光软件研究院院长，拥有机器学习博士学位。
他是开源技术的积极倡导者和推动者。对计算机科学及相关领域，特别是人工智能、Java技术、敏捷开发等领域有深入的见解。
他曾受邀在 InfoQ 和 IBM Developer Works 等网站撰写技术专栏。许多畅销书的作者。
着有《智慧的疆界》、《深入理解Java虚拟机》、《深入理解OSGi》、译《Java虚拟机规范》等作品。其中《深入理解Java虚拟机》于2011年出版第一版，现已出版至第三版。
该书已印刷超过35次，销量达30万册。不仅有良好的销量，而且有较好的口碑。
在中文计算机图书领域是公认的、罕见的。佳作。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-17
06-21
06-17
06-18
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用