TW洞见 | 我如何向HRMM介绍Microservice（上）

Posted 2021-04-24 思特沃克

今日洞见

本文作者及文中图片来自：ThoughtWorks - 刘夏。封面图片来自ThoughtWorks。

本文版权归【ThoughtWorks中国】（微信ID：思特沃克ThoughtWorks）。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。

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

1

从集中到分权

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

故事

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

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

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

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

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

在此次结构调整之后，大家的工作效率明显提升了。抱怨知识结构太复杂，无法短期适应工作的声音消失了。一个月之后，我们做了一个抽样调查，发现大家对自己的工作范围和内容都了如指掌。一些客户又重新和我们签订了合同。

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

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

从故事到项目

大多数项目也会像我们的创业公司一样，一开始大家一起干活，每一个人都是冲锋陷阵多面手。大家一起组成了应用程序的全部，而我们的车库就是数据库。这种组织结构代表了典型的 monolithic application。这种系统的逻辑架构是类似这样的。

在项目的早起，业务简单，吞吐不大，这种结构清晰，易于理解的架构非常实用。但是随着业务的增大，混在一起的代码不易理解。而最容易想到的解决办法就进行职责的划分。一统公司一开始在维持车库结构的情况下仅仅把人员上做了拆分。这种情形在实际项目中也存在。系统进入了多个服务共享一个数据库的阶段，而集成点在数据库上。

这种职责划分但又维持数据库集成的方式只应当作为过度阶段存在。程序永远都是逻辑+数据，而数据的混杂谈不上职责的独立。长期维持这种数据集成的状态容易出现业务下行，数据表达不一致等问题。从逻辑+数据的整体划分边界（称为模块，或者服务）势在必行。而在边界划定之后，就需要考虑独立的服务之间如何进行协作了。

点击下方 “阅读原文”更多精彩洞见。

↓↓↓

欢迎关注

新版技术雷达
各类干货洞见

精选职位招聘
活动预告总结

长按二维码可直接关注我们~