Microservice 概念

 

一天我司招财猫姐(HR 大人)问我，你给我解释一下 Microservice 是什么吧。故成此文。一切都是从一个创业公司开始的。

故事

最近的创业潮很是火爆，我禁不住诱惑也掺和了进去，建立了一家公司。为了表达个人抱负，取千秋万代，一统江湖之意。我给公司定下了一个很是响亮的名字叫作——一统。

从集中到分权

虽然说叫作一统可是凡是都要从头开始，公司成立之初有五个成员：罗密欧，朱丽叶，维克多，布拉伯还有老大——我。咱们五我的都是工程师出身，自身具有了很是优秀的学习能力，各个都是从业务到代码的好手，五我的一块儿作策划，搞市场，写程序，作运维，面对客户；可谓你中有我，我中有你，努力拼搏，好不热闹。为了吉利，咱们找了一个车库做为机房和资料室，上至合同，下至代码，全都放在里面。这就是一统最初的样子。

虽然创业艰难，大部分公司都在前两年倒下了，可是我大一统不但没有倒掉，还意外的获得了增加。客户从当初的一家猛增到一百家。这样即便咱们的团队再出色也应付不了这么多的客户了。挣钱仍是要命呢？

命得要，钱也得挣！怎么办呢？招人吧！咱们绞尽脑汁搜罗（挖角）市场上的人才，组成了巨型一统团队。咱们认为咱们团队中的任何成员都应该跟初创时期的五我的同样，能攻能守，内外兼修，可是……咱们发现这是不可能的，有些人擅长写代码而非面对客户，有些人善于作市场可是不喜欢算财务。后来出现了更加让人挠头的事情，有一个财务流程，问了5-6我的居然没有一我的可以完整的串起来。因而，我一个一个的问，最后才把整个流程从这些碎片知识里面串联起来。

这样的团队的服务质量可想而知，不久就接到了数十件客户投诉。竞争对手趁机抢占市场，一个欣欣向荣的公司瞬间就风雨飘摇了。

为了留住客户，咱们必须在扩张的同时可以保证服务质量。我发现目前最重要的问题就是职责不清晰，你们不知道本身应该干什么也不清楚怎么干，因而我抽调了各个业务部分的精干力量，总结流程，造成了客户及市场、财务/合同、技术运维、管理团队四个独立的业务部分。采起内部招聘的方式将人力分配到了这四个部门中。我指望将你们从纷繁的知识体系中解脱出来，每个不须要了解那么多的知识，集中力量关注本身的问题以提高效率和服务质量。

在这次结构调整以后，你们的工做效率明显提高了。抱怨知识结构太复杂，没法短时间适应工做的声音消失了。一个月以后，咱们作了一个抽样调查，发现你们对本身的工做范围和内容都了如指掌。一些客户又从新和咱们签定了合同。

正当我沾沾自喜的时候，发生了一个重大事件。因为咱们的资料室是对全公司开放的，任何成员均可以查看或修订其中的信息。客户及市场部的一个员工平时很是好学，对财务方面的知识掌握的很是系统。有一天，公司急需草拟一份财务清单，可是这个任务很是耗时，财务部门的同时当时正在月末审核，无暇抽身。这位热心的同窗就凭借本身出色的能力从资料室取来相应的材料完成了清单。三天后，财务部的罗密欧准备细化这个清单。可是清单的内容让他着实吃了一惊——清单上的填写内容和他们部门内约定格格不入。罗密欧只得本身从新完成了清单。一来一去让他的工做耽搁了一天，罗密欧向我抱怨道。无独有偶，其余部门也发生了一样的事情。这让我意识到只是把人员的职责进行划分并不能完全解决问题。咱们不能再继续混用一个资料室了，由于这样人人均可以任意修改各类资料，安全性很差不说还会形成填写格式混乱。因而我把财务部的资料放在了另外一个独立的屋子里，并给罗密欧单独配了钥匙。这样，任何想填写财务清单的人只能找财务部的人所要单据，而当单据缴回的时候也必须通过财务部的审核。鉴于财务部每月底都会很忙，在那时我会临时抽调人手去帮忙。

我但愿对其余部门作相应的整改，但这种动做幅度毕竟很大，所以，一段时间内还会有多个部门共用资料室。通过一个月的努力，咱们最终仍是淘汰了公用资料室。为每个部门都配备了独立资料室。虽然须要缴纳更多的房租，可是各部门再也没有犯以前的错误。

协做

如今咱们的资料室都独立了，再也没有办法像之前同样有须要就去公共资料室里取资料了。那么咱们应该如何进行协做呢？

串联协做

一个很是天然的想法是把各部门用业务流程穿起来。例如，若是洽谈一个订单，先由客户及市场部进行调查和谈判，而后由技术部制定解决方案，管理部审批以后由财务合同部拟定合同，最终递交管理部签署。

为了将这一方案执行下去，咱们对各个部门的人员进行了培训。例如，对于对于技术部，若是是洽谈一个订单，那么技术部须要给出解决方案，完成以后须要将方案递交管理部审批。相似的业务有不少，每个业务各个部门任务都不一样，而下游接收的部门也不同。可是个人同事们仍是克服了困难，将它们烂熟于胸。

业务调度员

业务变化是最日常的，一变就是一大把。如今对于洽谈订单的业务，咱们须要在技术方案给出以后先给财务部进行预算审核再递交管理部。这须要从新培训三个部门的人，洗脑同样的把他们以前的流程抹掉。一个业务变化还好，可是一下二三十个业务发生变化让你们抓狂。甚至有人说这和以前一大坨人一块儿作全部事情的时候没有什么差异。看来这种业务串联的方式是行不通了。

所谓我不入地狱谁入地狱，这种状况下我自告奋勇，入住市场部——由于这个部门是直接为客户服务的。我对全部的流程了如指掌，当业务来了的时候，有我去对业务进行协调。例如，当一个洽谈订单的业务到来的时候，我会先将他交给客户市场部进行谈判；结束后市场部将需求和意向书交给我，我再把需求交给技术部去制定解决方案；方案制定完毕以后技术部会把方案返回给我，我再把结果交给财务部审核…如此进行。这样，每个部门就不会因为业务变化从新接受培训了，也不用记住他们的下游应该是谁。你们以为，职责明确多了，工做轻松多了。

公司广播

如今我俨然成为了流程的中心，其余业务部门不须要关注业务流程的变化。这给咱们增长了不少灵活性，由于我一我的的变化速度要比一群人的变化速度快得多（你是独裁者吗喂）。可是个人大脑老是有限的，一年以后，经历了三四轮的业务变化，我已经开始不能准确的回忆某些业务细节。我不得不开始频繁的查询个人业务笔记来肯定个人下一步操做；此外，不停的往各部门送信也令我不堪重负。这时候，我但愿其余人可以为我分担。我决定化被动为主动，不禁我主动联络各个部门，而由各个部门主动接受任务。我在公司安装了一个大喇叭，话筒就在个人办公室里。当一个订单洽谈业务到来的时候我就朝着喇叭嚎：新订单来啦。客户和市场部专门关注新订单，由于按照流程，订单到来以后市场部要尽快投入谈判。因而他们会主动开始行动。当市场部工做完毕以后，他们会将谈判的结果、需求以及意向书拿到个人办公室里。我会再嚎：需求来啦。此时，技术部会从我这里拿走这些资料资料并开始工做。如此往复，直到项目完成。

这种协做方式令我没必要再操心信息在各部门之间的流转。各部门知道他们应该什么时候介入，我只须要对着大喇叭喊天然会有相关的部门将活干完。这样，我做为业务的中转中心，工做量不会随着业务的增加显著的增大（只要喊话就好了，至多就是增长喊话种类），而各部门也不用关心本身的下游究竟是谁，只须要关心我喊的话就好了。看起来这是一种很是方便的形式。可是这真的就又快又省吗？

有一天，来了一个新的订单。在我接到意向书和需求以后，我照例喊话：需求来啦！接着，我就出去吃饭了（真是资本家啊你）。等我回到了办公室，发现文档已经被拿走了，而结果尚未送过来。时间一天一天过去了，我手头的新订单越积越多，需求文档和意向书源源不断的送过来。到了第三天我实在是受不了了，想去查找文档的去向和任务的完成情况。这时候我才发现我根本无从下手，由于我不知道文档是谁拿走的，因而我便一个部门一个部门的去询问。但是因为业务的发展，如今咱们已经有20多个部门了，这种很是规的询问不只让我跑断了腿，并且为了查证，须要翻阅各部门成吨的业务日志，各部门的部长对此也很有微辞。我终于意识到——这种协做方式在令结构松散灵活的同时也极大的增长了监管的难度。必须采起额外的投入来弥补这一短板。

因而，专门监视各部门动向的“纪检委”：监管部出现了。一开始，我只是想确认一下各部门运做是否正常，有没有因为天灾人祸而出现团灭的现象。出于不对各部门添加新的压力的愿望，监管部会按期去肯定各部门走一圈看看是否都在好好干活（真是讨人嫌的部门啊），就像这样。

可是随着业务的发展，我但愿获得各个部门更加详尽的信息，例如，各部门是否积压了大量任务而须要帮助，在处理过程当中是否因为流程不合理而没法继续下去等等。须要收集的数据已经远远超过了监管部跑腿的速度。怎么办呢？若是我手头没有什么钱，我可能会下降监管部工做的周期，例如以前是半天一次，如今改为两天一次。可是我是土豪，因而我制定了监管汇报单，强制各部门在情况出现问题的时候主动向监管部汇报，就像这样。

隔离和协做的矛盾

从踌躇满志的创业开始到如今，我感慨于业务的扩大和公司规模的发展。也有一些会议例如 PCon 但愿咱们可以去介绍的结构划分和协做模式。可是每当我在工做之余静静思考的，却感到一些厌倦。咱们的协做真的好吗？随着职责的划分，咱们愈来愈专业化，互不影响的工做方式极大的增长了咱们的效率，良好的隔离让咱们的失误不至于扩散并可以横向扩展；而监控系统也告诉咱们一切尽在掌握。可是隔离同时也是壁垒。为了协做，咱们在这些壁垒上开了些小孔，为了严格控制进出，咱们制定了愈来愈多的规条，例如，信件应该怎么写，单据应该怎么填。回头看去，成百上千的规约连我也不能尽数，当我须要对个人公司作出变化的时候，若是变化仅仅发生在各个部门内部，这种结构的优点就显露无遗。可是若是设计到部门之间的协做，甚至部门的拆分合并，就会变得异常艰难。因为部门和规约的耦合是存在于脑内的，并不显露在外，修改已经存在的规约和部门结构每每不现实，只能花更多的钱去组建新的部门，逐步介入公司业务后淘汰旧有的部门。而这种周期动辄是以月计算的。有的时候，可能宁肯去接受新的方式从头开始，卖掉旧的公司，建立新的公司，而后继续轮回。

隔离既创造了灵活的单点变化也扩展造就了总体的僵化。细小的部门划分不能解决这个问题，由于部门越多，规约越多，实施成本越高（在例子中咱们并无考虑资料室的房租，监控的支出，可是现实中这每每是一个决定性因素）。单个部门结构的简化造就了总体的复杂。

所以，分部门就必定好吗？业务调度员就没有公司广播好吗？答案应该来源于你的现实，而不是理论。若是让我重来一次，我可能会慢一点，再慢一点。将来没法预计，针对当下的痛点作出反应可能不是最优的，可是倒是一个容易理解的思路。

那么什么是 Microservice 呢？

在上面的故事里面，哪一种是 microservice 架构呢？故事里面公司组织结构演化分红了几个部分，并非每个阶段的均可以称之为 microservice：

• 第一个阶段是多个部门共用一个资料室，这种状况每每并无摆脱数据库集成的事实（有些项目使用 Schema 对访问进行隔离，不在此列），不能称为 microservice；
• 第二个阶段是各个部门有本身的资料室，这是一个很是重要的改变，直到此时，各个部门才实现了彻底的隔离，可是还足以称为 microservice；
• 第三个阶段分三类：
  • 首先是串联协做。在这种方式下，一个部门的变化每每影响了其余部门，由于每个部门都须要知道业务的上游部门和下游部门，所以有比较紧密的耦合关系，没法独立变化。所以不足以称为 microservice；
  • 其次是业务调度员。这种方式下部门自身的变化不会扩散到其余部门，所以是能够独立决定和操做，只要部门足够小，这种结构能够称之为 microservice了；
  • 第三是公司广播。这种方式下的部门耦合更加松散，能够独立进行变化，在部门足够小的前提下能够称之为 microservice。

咱们的初衷是什么呢？构造一个系统能横向扩展以知足业务伸缩性，提供灵活变化的能力，又但愿变化的影响不要扩散。所以，若是一个架构能够称之为 microservice 架构，那么意味着：

• 每个 Service 能够进行独立部署；
• 每个 Service 都足够小，完成完整的定义清晰的职责；

业务调度员和公司广播两个例子的组织结构均可以成为 microservice 架构。可是他们之间并无绝对的优劣之分。选用哪种应当取决于实际要求。

故事映射

这个部分会将故事中的概念映射到实际的架构中以帮助理解。关于 microservice 的更多信息，推荐 Building Microservice 一书（虽然这本书也是 ThoughtWorks 的牛人写的，可是这真的不是软广啊）。

一统公司最开始时的组织结构表明了典型的 monolitic application。这种系统的逻辑架构是相似这样的。

而在部门划分共用一个资料库后，系统进入了多个服务共享一个数据库的阶段，集成点在数据库上。

在每个部门都拥有了本身的资料库以后，各个部门的隔离很是完全了。在串联协做的方式下，系统的结构是相似这样的。

这种结构没法作到服务的独立部署，所以应当避免。而业务调度员结构以下图所示。

若是你还记得那位勤劳的调度员（我），那么你就必定认识 Composer 这个特殊的服务。而最复杂的大喇叭喊话则是对应着以下的架构。

写在最后

Microservice 不是一种科学，而仅仅是实践。就像是 OO 同样。最终应当是需求，是人，决定架构而非架构决定需求。Microservice 是为 Business Capability 而建，是根据实际（或者痛点）作出的抉择。他解决了一些问题，可是并不能确定就是从此软件的发展方向。硬件的革新——不管是近期的电池技术的发展，仍是近乎黑科技的量子态传输，量子计算都有可能影响甚至颠覆今天造成的软件开发手段。就像是当年你们为了追求极致的执行效率试图将代码塞进 64K 的代码段同样，咱们今天奉为经典的东西将来可能只是茶余饭后的谈资。咱们能作的只有保持开放的心态，坚持辩证的观点，坚持从实际出发（我当年政治必定得高分了），寻找出最合适的解决方案。这也就是咱们不称本身为码农的理由之一吧。