这是我参加「第五届青训营 」伴学笔记创作活动的第 8 天
前言
记载参加青训营的每一天的笔记
本文是关于微服务的一些了解
微服务是什么
过去几年中呈现了“微服务架构”这一术语，它描绘了将软件运用程序规划为若干个可独立布置的服务套件的特定办法。尽管这种架构风格没有有精确的界说，但环绕事务才能、主动布置、端点智能以及言语和数据的涣散操控等安排来说，它们仍是存在着某些一同特征。
“微服务”——在拥挤的软件架构街道上又一个新名词。尽管咱们的天然倾向是对它轻视一瞥，但这一术语描绘了一种越来越具有吸引力的软件体系风格。在过去几年中，咱们现已看到许多项目运用了这种风格，到目前为止其成果都是正向的，以至于它变成了咱们 ThoughtWorks 许多同事构建企业运用程序的默认风格。但是惋惜的是，并没有太多信息能够概述微服务的风格以及怎么完结。
简而言之，微服务架构风格[1]是一种将单个运用程序开发为一套小型服务的办法，每个小型服务都在自己的进程中运转，并以轻量级机制（一般是 HTTP 资源 API）进行通讯。这些服务环绕事务功用构建，可经过全主动布置机制来独立布置。这些服务共用一个最小型的会集式办理，它们能够运用不同的编程言语编写，并运用不同的数据存储技能。
在开始解说微服务风格之前，将它与单体（monolithic）风格进行比较是有用的：单体运用程序被构建为单一单元。企业运用程序一般由三个部分构成：客户端用户界面（由用户机器上的浏览器中运转的 HTML 页面和 Javascript 组成）、数据库（由许多表组成，一般是在联络型数据库中办理）体系、服务器端运用程序。服务器端运用程序处理 HTTP 恳求，履行一些逻辑处理，从数据库检索和更新数据，挑选数据并填充到要发送到浏览器的 HTML 视图中。这个服务器端运用程序是一个全体——一个逻辑可履行文件[2]。对体系的任何更改都触及构建和布置新版其他服务器端运用程序。
这种单体服务器是构建这种体系的天然办法。处理一个恳求的一切逻辑都在一个进程中运转，允许你运用言语的基本功用将运用程序区分为类、函数和命名空间。需求注意的是，你能够在开发人员的笔记本电脑上运转和测验运用程序，并运用布置管道保证对程序做出的改动被适当测验并布置到出产环境中。你能够经过在负载均衡器后边运转许多实例来水平扩展全体块。
单体运用程序能够取得成功，但越来越多的人对它们感到不满——特别是在将更多运用程序布置到云的时分。改动周期被捆绑在一同——即便仅仅对运用程序的一小部分进行了更改，也需求重建和布置整个单体运用。跟着时间的推移，一般很难坚持杰出的模块化结构，也更难以坚持应该只影响该模块中的一个模块的更改。对体系进行扩展时，不得不扩展整个运用体系，而不能仅扩展该体系中需求更多资源的那些部分。
这些不满催生了微服务架构风格：将运用程序构建为服务套件。除了服务可独立布置、独立扩展的事实之外，每个服务还供给了一个结实的模块鸿沟，乃至允许以不同的编程言语编写不同的服务。他们也能够由不同的团队办理。
咱们并不以为微服务风格是新颖的或立异的，其本源至少能够追溯到 Unix 的规划原则。但咱们以为没有足够多的人考虑微服务架构，假如运用它，许多软件的开发会变得更好。
微服务架构的特征
尽管不能说微服务架构风格有正式的界说，但咱们能够测验描绘一下咱们以为的在符合这个标签的架构中，它们所具有的一些一同特征。与概述一同特征的任何界说相同，并非一切微服务架构都具有一切特征，但咱们的确希望大多数微服务架构都具有大多数特征。尽管咱们的作者一直是这个适当宽松的社区的活跃成员，但咱们的本意仍是测验描绘咱们两人在自己和自己所了解的团队的作业中所看到的状况。特别要说明的是，咱们没有制定一些相关的界说。
经过服务进行组件化
只需咱们参加软件职业，就一直希望经过将组件集成在一同来构建体系，就像咱们在物理世界中看到的事物的构建办法相同。在过去的几十年中，咱们现已看到了大多数言语渠道的公共软件库都取得了极大的发展。
在谈论组件时，就会碰到一个有关界说的难题，即什么是组件？咱们的界说是，组件是可独立更换和晋级的软件单元。
微服务架构也会运用软件库，但组件化软件的首要办法是拆分为多个服务。咱们把库界说为链接到程序并运用内存函数调用来调用的组件，而服务是一种进程外组件，经过 Web 服务恳求或长途进程调用等机制进行通讯。（这与许多面向方针程序中的服务方针的概念是不同的[3]。）
将服务作为组件（而不是库）的一个首要原因是服务能够独立布置。假如你有一个运用程序[4]是由单一进程里的多个库组成，任何一个组件的更改都会导致整个运用程序的重新布置。但假如运用程序可拆分为多个服务，那么单个服务的改动只需求重新布置该服务即可。当然这也不是绝对的，一些服务接口的修正或许会导致多个服务之间的协同修正，但一个好的微服务架构的意图是经过内聚服务鸿沟和服务协议的演进机制来最小化这些协同修正。
将服务用作组件的另一个成果是更明晰的组件接口。大多数言语没有一个杰出的机制来界说显式发布的接口。一般，它仅仅文档和规矩来阻止客户端损坏组件的封装，这会导致组件之间过于紧耦合。经过运用显式长途调用机制，服务能够更轻松地防止这种状况。
像这样运用服务的确存在一些不好的地方。长途调用比进程内调用更昂贵，长途 API 需求规划成较粗的粒度，这一般更难以运用。假如你需求更改组件之间的职责分配，那么当你跨过进程鸿沟时，这种组件行为的改动会愈加难以完结。
近似地，咱们能够把一个个服务映射为一个个运转时进程，但这仅仅是一个近似而已。一个服务或许包含多个一直一同开发和布置的进程，比方一个运用体系的进程和仅由该服务运用的数据库。
环绕事务才能进行安排
在将大型运用程序拆分为多个部分时，办理层往往侧重于技能层面，从而导致 UI 团队、服务器端逻辑团队、数据库团队的区分。当团队依照这些办法分开时，即便是简略的更改也或许导致跨团队项意图时间和预算批准。一个聪明的团队将环绕这个进行优化，“两害相权取其轻”——只需将逻辑强制运用到他们能够访问的任何运用程序中。换句话说，逻辑无处不在。这是康威定律[5]的一个比如。
任何规划体系（广义上的）的安排都会产生一种规划，其结构是安排通讯结构的副本。 —— 梅尔文•康威，1967 年
微服务选用不同的区分办法，它是环绕事务功用将体系拆分为多个服务 。这些服务为该事务领域选用广泛的软件完结，包含用户界面、耐久化存储和任何外部协作。因而，团队是跨功用的，包含开发所需的悉数技能：用户体会、数据库和项目办理。
以这种办法组建的一家公司是 www.comparethemarket.com。跨功用团队担任构建和运营每个产品，每个产品拆分为多个独立的服务，彼此经过音讯总线来通讯。
大型单体运用程序也能够环绕事务功用进行模块化，尽管这不是常见的状况。当然，咱们会敦促构建单体运用体系的大型团队依据事务线来将自己分解为若干小团队。咱们在这里看到的首要问题是，它们往往环绕太多的上下文进行安排。假如单体跨过了模块鸿沟，对团队的个体成员来说，很难将它们装入短期的记忆中。此外，咱们看到模块化出产线需求许多的规矩来履行。服务组件所要求的愈加明晰的别离，使得它更简略坚持团队鸿沟明晰。
是产品不是项目
咱们看到的大多数运用程序开发作业都运用这样一个项目形式：方针是交给一些软件，然后就完工了。一旦完结后，软件将移交给保护安排，然后构建它的项目团队也随之解散了。
微服务支撑者倾向于防止这种形式，而是以为团队应该担任产品的整个生命周期。对此一个一同的启示是亚马逊的 “you build, you run it” 的概念，开发团队对出产中的软件负悉数职责。这使开发者常常触摸他们的软件在出产环境怎么作业，并增加与他们的用户联络，由于他们有必要承当至少部分的支撑作业。
产品心态与事务才能的联络严密相连。要继续关注软件怎么协助用户提升事务才能，而不是把软件看成是行将完结的一组功用。
没有理由说为什么这种办法不能用在单一运用程序上，但较小的服务粒度，使得它更简略在服务开发者和用户之间树立个人联络。
智能端点和哑管
在不同进程之间树立通讯时，咱们现已看到许多产品和办法，都着重将许多的智能特性放入通讯机制自身。一个很好的比如是企业服务总线（ESB），其间 ESB 产品一般包含用于音讯路由、编列、转化和运用事务规矩的杂乱东西。
微服务社区倾向于选用另一种办法：智能端点和哑管。根据微服务构建的运用程序的方针是尽或许的解耦和尽或许的内聚——他们具有自己的领域逻辑，他们的行为更像经典 UNIX 理念中的过滤器——接纳恳求，运用适当的逻辑并产生呼应。运用简略的 REST 风格的协议来编列它们，而不是运用像 WS-Choreography 或许 BPEL 或许经过中心东西编制(orchestration)等杂乱的协议。
最常用的两种协议是带有资源 API 的 HTTP 恳求-呼应和轻量级音讯传递[8]。对第一种协议最好的表述是
自身便是 web，而不是隐藏在 web 的后边。 ——Ian Robinson
微服务团队运用的规矩和协议，正是构建万维网的规矩和协议(在更大程度上是 UNIX 的)。从开发者和运营人员的角度讲，一般运用的资源能够很简略的缓存。
第二种常用办法是在轻量级音讯总线上传递音讯。挑选的基础设施是典型的哑的(哑在这里只充任音讯路由器)——像 RabbitMQ 或 ZeroMQ 这样简略的完结仅仅供给一个可靠的异步交换结构 ——在服务里，智能特性仍旧存在于那些出产和消费许多音讯的各个端点中，即存在于各个服务中。
单体运用中，组件都在同一进程内履行，它们之间经过办法调用或函数调用通讯。把单体变成微服务最大的问题在于通讯形式的改动。一种幼稚的转化是从内存办法调用转变成 RPC，这导致频频通讯且功用不好。相反，你需求用粗粒度通讯代替细粒度通讯。
去中心化的办理
会集办理的一个后果是单一技能渠道的规范化发展趋势。阅历标明，这种办法正在收缩 ——不是每个问题都是钉子，不是每个问题都是锤子。咱们更喜爱运用正确的东西来完结作业，而单体运用程序在必定程度上能够运用言语的优势，这是不常见的。
把单体的组件割裂成服务，在构建这些服务时能够有自己的挑选。你想运用 Node.js 开发一个简略的报告页面？去吧。用 C++ 完结一个特别粗糙的近乎实时的组件？好极了。你想换用一个更适合组件读操作数据的不同风格的数据库？咱们有技能来重建它。
当然，仅仅由于你能够做些什么，而不意味着你应该这样做——但用这种办法区分体系意味着你能够挑选。
团队在构建微服务时也更喜爱用不同的办法来合格。他们更喜爱出产有用的东西这种主意，而不是写在纸上的规范，这样其他开发者能够用这些东西处理他们所面对的类似的问题。有时，这些东西一般在实施中收获并与更广泛的群体同享，但不彻底运用一个内部开源模型。现在 git 和 github 现已成为事实上的版别操控体系的挑选，在内部开放源代码的实践也正变得越来越常见。
Netflix 是遵循这一理念的一个很好的比如。特别是，以库的办法共享有用的且经过市场检验的代码，这激励其他开发者用类似的办法处理类似的问题，同时还为选用不同办法敞开了大门。同享库倾向于聚集在数据存储、进程间通讯和咱们接下来要深入评论的基础设施主动化的共性问题。
关于微服务社区来说，开销特别缺少吸引力。这并不是说社区不重视服务合约。恰恰相反，由于他们有更多的合约。仅仅他们正在寻找不同的办法来办理这些合约。像 Tolerant Reader 和 Consumer-Driven Contracts 这样的形式一般被用于微服务。这些援助服务合约在独立进化。履行消费者驱动的合约作为构建的一部分，增加了决心并对服务是否在运作供给了更快的反应。事实上，咱们知道澳大利亚的一个团队用消费者驱动的合约这种形式来驱动新事务的构建。他们运用简略的东西界说服务的合约。这已变成主动构建的一部分，即便新服务的代码还没写。服务仅在满意合约的时分才被创立出来 – 这是在构建新软件时防止 “YAGNI”[9] 窘境的一个高雅的办法。环绕这些生长起来的技能和东西，经过削减服务间的暂时耦合，约束了中心合约办理的需求。
或许去中心化办理的最高境界便是亚马逊广为流传的 build it/run it 理念。团队要对他们构建的软件的各方面担任，包含 7*24 小时的运营。这一级其他职责下放绝对是不规范的，但咱们看到越来越多的公司让开发团队负起更多职责。Netflix 是选用这一理念的另一家公司[11]。每天清晨 3 点被传呼机叫醒无疑是一个强有力的激励，使你在写代码时关注质量。这是关于尽或许远离传统的会集办理形式的一些主意。
涣散数据办理
数据办理的去中心化有许多不同的呈现办法。在最抽象的层面上，这意味着使体系间存在差异的世界概念模型。在整合一个大型企业时，客户的出售视图将不同于支撑视图，这是一个常见的问题。客户的出售视图中的一些事情或许不会呈现在支撑视图中。它们的确或许有不同的特色和(更坏的)一同特色，这些一同特色在语义上有微妙的不同。
这个问题常见于运用程序之间，但也或许产生在运用程序内部，特别当运用程序被区分成别离的组件时。一个有用的思想办法是有界上下文(Bounded Context)内的领域驱动规划(Domain-Driven Design, DDD)理念。DDD 把一个杂乱域区分成多个有界的上下文，而且映射出它们之间的联络。这个进程对单体架构和微服务架构都是有用的，但在服务和上下文鸿沟间有天然的相关性，鸿沟有助于澄清和加强别离，就像事务才能部分描绘的那样。
和概念模型的去中心化决议方案相同，微服务也去中心化数据存储决议方案。尽管单体运用程序更喜爱单一的逻辑数据库做耐久化存储，但企业往往倾向于一系列运用程序共用一个单一的数据库——这些决议是供应商授权答应的商业形式驱动的。微服务更倾向于让每个服务办理自己的数据库，或许同一数据库技能的不同实例，或彻底不同的数据库体系 – 这便是所谓的混合耐久化(Polyglot Persistence)。你能够在单体运用程序中运用混合耐久化，但它更常呈现在为服务里。
对跨微服务的数据来说，去中心化职责对办理晋级有影响。处理更新的常用办法是在更新多个资源时运用事务来保证一致性。这个办法一般用在单体中。
像这样运用事务有助于一致性，但会产生显著地暂时耦合，这在横跨多个服务时是有问题的。分布式事务是出了名的难以完结，因而微服务架构着重服务间的无事务协作，对一致性或许仅仅最后一致性和经过补偿操作处理问题有明晰的认知。
对许多开发团队来说，挑选用这样的办法办理不一致性是一个新的挑战，但这一般与事务实践相匹配。一般事务处理必定程度的不一致，以快速呼应需求，同时有某些类型的逆转进程来处理过错。这种权衡是值得的，只需修复过错的代价小于更大一致性下损失事务的代价。
基建主动化
基础设施主动化技能在过去几年中产生了巨大改变——特别是云和 AWS 的发展下降了构建、布置和运转微服务的操作杂乱性。
许多运用微服务构建的产品或体系都是由具有丰厚的继续交给和继续集成阅历的团队构建的。以这种办法构建软件的团队广泛运用基础设施主动化技能。如下面显现的构建管道所示。
由于这并不是一篇关于继续交给的文章，咱们在这里只关注继续交给的几个要害特性。咱们希望有尽或许多的决心保证咱们的软件正常运转，因而咱们进行了许多的主动化测验。想让软件到达“晋级”(Promotion)状况从而“推上”流水线，就意味着要在每一个新的环境中，对软件进行主动化布置。
一个单体运用程序能够十分愉快地经过这些环境构建、测验和推进。事实证明，一旦你为单体投入了主动化全体出产，那么布置更多的运用程序似乎不再那么可怕了。请记住，继续交给的方针之一便是让“布置”作业变得“单调”，所以无论是一个仍是三个运用程序，只需布置作业仍旧很“单调”，那么就没什么可忧虑的了[12]。
咱们看到团队许多的基础设施主动化的另一个领域是在办理出产环境中的微服务。与咱们上面的断语（只需布置很无聊）比较，单体和微服务之间没有太大的差异，但是每个布置的运转环境或许会截然不同。
规划时为毛病做好准备
运用服务作为组件的成果是，需求规划运用程序以便它们能够容忍服务的失利。假如服务供给者商不可用，任何服务呼叫都或许失利，客户有必要尽或许高雅地对此做出呼应。与单体规划比较，这是一个缺陷，由于它这会引进额外的杂乱性来处理它。成果是微服务团队不断反思服务失利是怎么影响用户体会的。Netflix 的 Simian Army 能够引发服务乃至数据中心的毛病在作业日产生毛病，从而来测验运用程序的弹性和监控才能。
出产中的这种主动化测验足以让大多数运维团队振奋得浑身颤栗，就像在一周的长假行将到来前相同。这并不是说单体架构风格不能构建先进的监控体系——仅仅依据咱们的阅历，这在单体体系中并不常见算了。
由于服务或许随时产生毛病，因而能够快速检测毛病并在或许的状况下主动恢复服务就显得至关重要。微服务运用程序十分重视运用程序的实时监控，比方查看架构元素（数据库每秒取得多少恳求）和事务相关衡量（例如每分钟收到多少订单）。语义监控能够供给呈现问题的早期预警体系，从而触发开发团队跟进和查询。
这关于微服务架构来说尤为重要，由于微服务偏好编列和事件写作，这会导致一些紧迫状况。尽管许多权威人士关于偶尔事件的价值持积极情绪，但事实是，“突发行为”有时或许是一件坏事。监控至关重要，它能够快速发现不良紧迫行为并进行修复。
单体体系也能够像微服务相同完结通明的监控——事实上，它们也应该如此。不同之处在于你有必要能够知道在不同进程中运转的服务在何时断开了衔接。关于同一进程中的库，这种通明性用途并不大。
微服务团队希望看到针对每个服务的杂乱监控和日志记载，例如显现“运转/宕机”状况的仪表盘以及各种运维和事务相关的指标。有关断路器状况，当前吞吐量和延迟的详细信息也是咱们在作业中常常遇到的其他比如。
演化规划
微服务从业者一般有进化规划的布景，并把服务分解视为进一步的东西，使运用程序开发人员能够操控运用程序中的更改，而不会下降改动速度。改动操控并不必定意味着改动的削减——在正确的情绪和东西的协助下，你能够对软件进行频频，快速且有杰出操控的更改。
每逢要企图将软件体系分解为组件时，你就会面对这样的决议方案，即怎么进行拆分——咱们决议拆分运用程序的原则是什么？组件的要害特色具有独立替换和可晋级性的特色[13]——这意味着咱们寻找这些点，想象怎么在不影响其协作者的状况下重写组件。实际上，许多微服务组经过明晰地希望许多服务被抛弃而不是长时间演变来进一步考虑这一点。
Guardian 网站是规划和构建成单体运用程序的一个很好的比如，但是它也在微服务方向上不断发展演化。原先的单体体系仍然是网站的核心，但他们更喜爱经过构建一些微服务 API 的办法来增加新的功用。这种办法关于本质上是暂时的功用特别方便，例如处理体育赛事的专用页面。网站的这一部分能够运用快速开发言语快速组合在一同，在赛事结束后当即删除。咱们在金融机构看到过类似的办法，为市场机会增加新服务，并在几个月乃至几周后丢弃。
这种着重可替换性的特色，是模块化规划一般性原则的一个特例，即经过改变形式来驱动模块化的完结[14]。大家都愿意将那些同时产生改变的东西放在同一个模块，很少改变的体系模块应该与目前正在阅历许多变动的体系处于不同的服务中。假如你发现自己重复更改两项服务，那就标明它们应该兼并了。
将组件放入服务中能够为更细粒度的发布方案增加机会。关于单体来说，任何更改都需求完好构建和布置整个运用程序。但是，运用微服务，你只需求重新布置你修正的服务。这能够简化并加快发布进程。缺陷是你有必要忧虑一项服务的改变会打破其消费者。传统的集成办法是测验运用版别操控来处理这个问题，但微服务世界中的偏好是仅仅把运用版别操控作为最后的手段。咱们能够经过规划服务尽或许容忍服务供给者的改变来防止许多的版别操控。
