解析微服务架构（二）微服务架构综述

发布时间： 2024-09-08 10:44:06 来源：天博app

在解析微服务架构(一) 单块架构系统和其面临的挑战中，我们谈到了随市场的加快速度进行发展，业务的逐步扩大，单块架构应用面临着慢慢的变多的挑战，其改造与重构势在必行。

微服务架构（Microservice Architect）是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户更好的提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，还可以被独立的部署到生产环境、类生产环境等。

微服务架构虽然诞生的时间并不长，但其在各种演讲、文章、书籍上所出现的频率已经让很多人意识到它对软件架构领域所带来的影响。

其实，微服务的诞生并非偶然。它是网络快速地发展，敏捷、精益、持续交付方法论的深入人心，虚拟化技术与DevOps 文化的快速发展以及传统单块架构无法适应快速变化等多重因素的推动下所诞生的产物：

过去的十年中，互联网对我们的生活产生了翻天覆地的变化。购物、打车、订餐、支付，甚至美甲、洗车等，想到的，想不到的活动都能够最终靠互联网完成，慢慢的变多的传统行业公司也开始依赖网络技术打造其核心竞争优势。互联网时代的产品通常有两类特点：需求变化快和用户群体庞大。在这种情况下，如何从系统架构的方面出发，构建灵活、易扩展的系统，快速应对需求的变化；同时，随着用户量的增加，如何保证系统的可伸缩性、高可用性，成为系统架构面临的挑战。

纵观 IT 行业过去的十年，敏捷、精益、持续交付等价值观、方法论的提出以及实践，让很多组织意识到应变市场变化、提高响应力的重要性。精益创业（Lean Startup）帮助组织分析并建立最小可实行产品（Minimum Viable Product），通过迭代持续改进；敏捷方法帮助组织消除浪费，通过反馈不断找到正确的方向；持续交付帮助组织构建更快、更可靠、可频繁发布的交付机制。经过这些方法论以及实践的推行和尝试后，从宏观上而言，大部分组织已经基本上形成了一套可遵循、可参考、可实施的交付体系。这时候，逐渐完善并改进各个细节的需求就会更加强烈。所谓细节，就是类似怎么样找到灵活性高、扩展性好的架构方式、如何用更有效的技术、工具解决业务问题等。

虚拟化技术和基础设施自动化 (Infrastructure As Code) 的加快速度进行发展极大的简化了基础设施的创建、配置以及系统的安装和部署。譬如云平台的成熟以及像ChefPuppetAnsible等工具的使用，让更多的基础设施可以通过自动化的方式动态创建。同时，容器化技术的发展以及Docker的出现，更是将虚拟化技术推向了一个史无前例的高潮。另外，DevOps 文化的推行打破了传统开发与运维之间的壁垒，帮助组织形成更高效的、开发与运维高度协作的交付团队。这些技术与文化的加快速度进行发展，极大程度上解决了传统环境创建难、配置难以及‘最后一公里’的部署难、交付难等问题，成为推动微服务诞生、发展的主要的因素之一。

几年前我们熟悉的传统 IT 系统，也可以称之为单块架构系统，是以技术分层，譬如逻辑层、数据层等。但随着客户的真实需求个性化、产品生命周期变短、市场需求不稳定等因素的出现，单块架构系统面临着慢慢的变多的挑战。因此，怎么样找到一种更有效的、更灵活、更适应当前互联网时代需求的系统架构方式，成为大家关注的焦点。

早在 1996 年，Gartner 就提出面向服务架构（SOA）。SOA 阐述了“对于复杂的企业 IT 系统，应按照不同的、可重用的粒度划分，将功能相关的一组功能提供者组织在一起为广大购买的人提供服务”，其目的是未解决企业内部不同 IT 资源之间无法互联而导致的信息孤岛问题。

2002 年，SOA 被称作现代应用开发领域最重要的课题之一，其正在帮企业从资源利用的方面出发，将 IT 资源整合成可操作的、基于标准的服务，使其能被重新组合和应用。

但是，由于 SOA 本身的广义性以及抽象性，在其诞生的相当长一段时间内，人们对 SOA 存在着不同的认知和理解。

实际上，微服务架构并不是一个全新的概念。仔细分析 SOA 的概念，就会发现，其和我们今天所谈到的微服务思想几乎一致。那在 SOA 诞生这么多年后，为什么又提出了微服务架构呢？

鉴于过去十几年互联网行业的快速地发展，以及敏捷、持续集成、持续交付、DevOps，云技术等的深入人心，服务架构的开发、测试、部署以及监控等，相比我们提到的传统的 SOA 实现，已经大相径庭，主要区别如下表所示：

SOA 实现微服务架构实现企业级，自顶向下开展实施团队级，自底向上开展实施服务由多个子系统组成，粒度大一个系统被拆分成多个服务，粒度细客户服务总线，集中式的服务架构无集中式总线，松散的服务架构集成方式复杂（ESB/WS/SOAP）集成方式简单（HTTP/REST/JSON）单块架构系统，相互依赖，部署复杂服务都能独立部署相比传统 SOA 的服务实现方式，微服务更具有灵活性、可实施性以及可扩展性，其强调的是一种独立测试、独立部署、独立运行的软件架构模式。

其实，即便了解了上面的介绍，也很难对微服务下一个准确的定义。就像 NoSQL，我们谈论了好几年的 NoSQL，知道 NoSQL 代表着什么样的含义，也能够准确的通过不同的应用场景选不一样的 NoSQL 数据库，但是我们仍旧是很难对它下一个准确的定义。类似的，关于什么是‘函数式编程’，也或多或少存在同样的窘境。我们大家可以轻松的选择不同的函数式编程语言，能轻松的写出函数式编程风格的代码，但很难对什么是函数式编程下一个准确的定义。

实际上，从业界的讨论来看, 微服务本身并没有一个严格的定义。不过，ThoughtWorks 的首席科学家，马丁 - 福勒先生对微服务的这段描述，似乎更加具体、贴切，通俗易懂：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户更好的提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，还可以被独立的部署到生产环境、类生产环境等。另外，应当尽可能的避免统一的、集中式的服务管理机制，对具体的一个服务而言，应依据业务上下文，选择正真适合的语言、工具对其进行构建。

随着市场的加快速度进行发展，业务的逐步扩大，单块架构应用面临着慢慢的变多的挑战，其改造与重构势在必行。而微服务架构的诞生，是网络快速地发展，虚拟化技术应用以及持续交付、DevOps 深入人心的综合产物。随着客户的真实需求个性化、产品生命周期变短，微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时，以 Docker 为代表的容器虚拟化技术的盛行，将大大降低微服务实施的成本，为微服务落地以及大规模使用提供了坚实的基础和保障。

王磊，ThoughtWorks 公司首席咨询师。开源软件的爱好者和贡献者，社区活动的参与者，Practical RubyGems 的译者，GDCR西安的组织者。于 2012 年加入 ThoughtWorks, 为国内外诸多客户提供项目交付和咨询服务；在加入 ThoughtWorks 之前，曾就职过多家知名外企，有着非常丰富的敏捷项目实战经验。目前致力于微服务架构、虚拟化容器、持续交付、以及 DevOps 的研究与实践。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至也欢迎各位通过新浪微博（@InfoQ@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群

为什么需要分布式系统，而不是传统的单体架构。主要有两方面原因：增大系统容量和加强系统可用。

InfoQ中文站的电子杂志《架构师》（2011年4月刊）出炉了。本期的主编是InfoQ中文站原创团队编辑熊节。互联网的发展对软件组织快速响应客户的真实需求的能力提出了更高的要求，众多技术与方法都致力于缩短交付周期、加快反馈频率。敏捷软件开发能够在开发阶段有效缩短交付周期，然而大部分软件组织的运维团队与开发团队之间任旧存在明显的鸿沟。本期《架构师》月刊关注业界如何将敏捷思想延伸扩展至运维工作，邀请一些专家从自己的实践经验出发，撰稿讲述关于这一些内容的故事...

Gartner分析师Roy Schulte是SOA方面的专家，他参与编写了1996年那份为业界引入SOA这一术语的Gartner报告。前不久Susan Hall对他进行了采访。此次采访试图回答这样一个问题，即是否应该重新调整对SOA的期待了？

从谷歌的搜索指数来看，微服务的热度在进入2017年后突然爆发，各大一线网络公司也纷纷将这一技术引入并在实际业务中落地。

不知从何时起，与同事，面试者，面试官谈起架构理念，总是绕不开微服务。甚至有时候听到这三个字的时候，脑壳会痛，相似的还有中台, 总觉得是旧瓶装新酒。当然此时的盛行是有其原因的，猜测根本原因是容器化的盛行。

微服务系统比我们想象的要复杂得多。微服务给我们大家带来了诸多好处，同时也对我们提出了更高的要求。Martin Fowler为我们提出了三点建议，让我们分析微服务是不是适合我们。

Salseforce是云计算先驱，也是全球知名的CRM服务提供商。在20多年前就超前地提出了云计算和SaaS服务的概念，如今已是全球领先的云计算应用提供者。

Buzzfeed工程师团队分享了他们的部署演化做法。他们构建了一个称为Rig的内部框架，在其中使用了Docker、AWS ECS和Jenkins等工具，将先前需数日的基于单体应用的部署，演化为每日可达150次部署。由此实现了迁移到面向服务的架构，并构建了一个协作度更高的工程团队。

面向服务架构(SOA) 带给我们的思考不仅是拆分大型的系统为个性化的服务，还包括使用集中控制构建生产者驱动的庞大服务。Rebecca Parsons在QCon伦敦大会的演讲中指出，微服务带我们重新思考为什么SOA是有道理的这一基本概念。

最近，ZapThink发表了一篇讨论敏捷和SOA的文章：敏捷企业架构并非矛盾修饰法！。其独特之处在于从SOA的角度对敏捷宣言（Agile Manifesto）进行了重新诠释，提出了应用于SOA领域的4项原则。

今天我想再和你做一次分享，一起聊聊在2019年，容器技术生态会发生些什么。

有两个单向链表（链表长度分别为 m，n），这两个单向链表有可能在某个元素合并，如下图所示的这样，也可能不合并。现在给定两个链表的头指针，在不修改链表的情况下，如何快速地判断这两个链表是否合并？如果合并，找到合并的元素，也就是图中的 x 元素。

当SOA 2.0风头已过，REST vs SOA vs Web服务的争论也不像之前那么激烈的时候，业界又有一些人开始宣扬面向Web的架构（WOA）。可这和现有的东西有任何区别吗（比如REST）？如果有的话，它是什么，它又是怎么样帮助开发者和部署者的呢？来自Burton Group的Anne Thomas Manes认为这一术语有些过头了，也并没有为现在的争论带来任何的价值。