# 团队架构

在传统的SOA架构中我们以系统为边界进行划分，通过标准的协议实现系统间交互，在这一体系架构下成员归属于某个具体系统，工作任务即为所属系统的需求，所对应的组织结构会相对稳定、清晰，而微服务架构以服务的粒度进行划分，要求打破系统边界实现更小粒度的服务级重用，这带来的结果是随着业务的增长技术架构的重心会越来越下沉到公共服务层，逐渐形成我们现在常说的大中台小前台体系，可以让前台业务项目做得很“薄”，这时我们发现开发一个项目原本拉一个新的业务开发团队就可以独立完成，但现在有很多公共的服务可以重用，新的业务开发团队人员会减少、项目的工期会缩短，但与之而来是需要有大量跨团队的沟通协调、开发测试工作，这就与我们之前的团队管理有比较大的区别。上面的情况会出现在服务化相对成熟的公司，对于刚开始做微服务化的公司而言没有那么多可以重用的服务，如何通过一个个项目的迭代实现从0到1的服务化建设，如何在一个中大型项目中设计符合微服务体系的团队架构成了项目成败的关键之一，这是每个项目负责人在立项时不得不考虑的问题。

笔者的工作中发现很多项目都喜欢偏向于将所有人“坐在一起”办公，一个核心原因是方便沟通，但这样的做法在微服务下真的合适吗？其实50多年前就有人给出了答案，这就是康威定律 [Conway's Law](http://www.melconway.com/Home/Conways_Law.html)，它的核心结论之一是任何系统的设计形态与其组织形态紧密相关，即什么样的组织结构产生什么样的系统结构。那么一个管理集权、工作地点集中、编码规范一致的团队中必然产生一个设计语言统一、业务处理流程顺畅，很“优雅”的系统。但我细想一下，这真的优雅吗？凡事都有两面性，在系统复杂度不高时，这种组织结构产生的系统架构是非常正面的。但它的最大的问题在于解决方案过于简单粗暴，在大中型项目中导致的问题有：

**可扩展性差** 一个可持续发展的项目在代码及架构上必定是要求可扩展的，要能适应新需求的迭代，这是传统架构面临的主要问题之一，所以我们要微服务化以实现功能划小与解耦，但如果所有服务都由同一个团队设计开发极可能导致架构失控。在工作中我们时常听到管理者对员工说类似的话：“大家都是一个公司的，不要叫你们xx，我们xx”，“不要以为把自己的事情做完就可以了，别人的事就不管不顾了”…… 笔者认为在意识形态上大家保持统一这没问题，但到具体工作如果不分你我那就不合适了，一个团队中模块的边界往往不会定义得很清晰，导致一些功能无法找到归属，而另一些功能却又看似可以放到多个模块中实现，出现这些情况时比较常见的做法哪个模块的开发有空则划到哪个模块中，反正大家都是一个团队嘛。而就是这种自己人不分彼此的将就态度使得系统的结构变得越来越乱。

**缺乏抽象思维** 大家都以完成这一产品为目标，所以系统设计不会考虑过多的例外，功能的扩展性、重用性不高，比如注册时会发验证码短信，短信开发的同事提供了如下发送接口：

```
def result_code send(phone,message)
```

这看上去很正常是吧，但接下贷后说我们要发催收短信，这类短信要与注册短信使用不同通道（注册是生产类，催收属于营销类），那么接口会改成这样：

```
def result_code send(phone,message,channel)
```

这就完了？后期业务上又增加了其它短信，而短信发送的模板要报备，所以一个更合理的做法是传入模板id和变量，让渠道绑定到模板：

```
def result_code send(phone,templateId,parameters)
```

如上我们看到短信作为一个比较独立的功能如果只去考虑当下的业务就会变得极不稳定，与业务高度耦合进而失去的扩展与重用能力。

**技术单一闭塞** 同一个团队技术选型会相对统一，所以不会过多考虑使用差异化的技术解决特定的问题，同一个团队一般只会有一到两名技术架构师，架构师的个人经验会主导整体的技术方案，在保证技术统一性的同时也将失去尝试新技术的机会进而导致技术选型上固步自封。

**成员缺乏斗志** 树挪死，人挪活，长期待在一个团队做一个项目会让人格积极的员工倦怠进而离职，让没有追求的员工成为“老白兔”，降低了项目交付效率不说对这些员工本身也是极不负责的。

所有如果我们面对的是复杂的、长周期的项目时，就要用微服务的思想以上一章节介绍的服务划分手段将一个大系统分解成多个服务或子系统，尽量重用已有服务，将有共性可以重用的服务交由平台部门研发，以实现更好的兼容重用能力，相应地 `将大的团队拆分成一个个小团队，由于功能划分小每个团队可以更容易地明确目标、任务及验收要求，每个小团队可以有相对独立的架构、开发与测试，允许小团队相对自由地做技术选型，相较于大团队，小团队的生命周期更短，目标清晰，责任明确且更加灵活机动`，比如在完成某几个关联服务或某个子系统后部分人员就会拆分到其它团队以支援诸如二期、三期的需求。人员在各小团队内的流动会让不同团队间发生思想碰撞，团队间会相互引入及输出好的经验形成良性循环。

当然读者会担心这种流动及自主的技术选型会不会失控？我们说铁打的营盘流水的兵，项目管理者最大的考验是要保证核心的稳定，自由都是相对的，必须在负责人所能控制的限度内，所以项目负责人的高度及能力很大程度上决定了实施上的灵活及自由度，具体而言需要确保的是：

* 系统的整体架构设计是稳定的，不易变，这要求在公司层面有规范的架构设计指导建议及公司级别的技术栈选型要求
* 核心服务或子系统的划分是明确的，边界及功能是清晰，这要求系统或服务的立项需要有明确的流程，需要经由业务专家组、技术委员会审评
* 系统的技术与业务架构师、各小团队的骨干成员是相对稳定的，谁都可以离职，只要这些人还在项目就可以继续运转
* 基础规范是统一，如代码质量要求、测试及交付流程、设计及接口文档等，所有的自由发挥必须建立在符合这些规范之上
* 运维集权，开发、测试甚至架构设计都可以让小团队相对自主，但运维流程及管理必须是集中的，项目实施中运维的重要性不亚于前期的设计开发与测试，运维能力关乎生产质量，如果每个小团队有自己独立的运维会导致后期出现诸如网络不通、服务启动的依赖顺序不对、服务缺乏统一监控等问题
* 给成员以归属感及成就感，成员在各小团队间的流动不能过于频繁，不同的成员有不同的限度，要尊重他们的想法，做为大团队的一分子要给予他们归属感，要注意在领导关怀、团队活动、生日祝福等方面的建设，对表现突出的员工要及时地表扬让他们有成就感

微服务体系不是一蹴而就的，对应的团队架构亦如此，从上可以看出要实现团队按服务划小的前提有很多，总结而言至少需要有集团或公司层面的业务专家组、技术委员会负责整体把控，需要有相对统一的研发（立项、开发、测试、运维）流程。

工作中笔者也时常听到这样的声音“这是他们团队的问题”，“这不应该我们来做”。很多管理者都很反感这些，正如上面说的，都是一个公司的，不能分彼此，有失团结。这里笔者提出相反的观点：

**“这是他们团队的问题”** 表明的是对待责任的态度，管理上各组织单位的权责必须明确，要不得“你好我好大家好”一团和气的作风，“这是他们团队的问题”带来的好处是会刨根问底找到问题的本源，当所有团队都知道出问题甩不了锅时就会更重视质量、流程管理。

**“这不应该我们来做”** 表明的是对任务及边界的理解，本书不止一遍提到边界划分的重要性，我们可以通过上一章节的一些指导方法划分，但业务总是变化的、架构设计的能力也可能是有限的，所以服务的设定及边界的划分往往是需要各团队一起制定及修正的，“这不应该我们来做”只有在一次次这样的讨论中才能形成最适合的服务规划。

所以笔者会肯定这些声音，管理要乐于听到不同的声音，一些看似刺耳的声音可能会是对团队最有帮助的。当然有一点必须坚持的立场是所有这些声音都是对事不对人的。

笔者有时会比较刻意地控制团队间的沟通频次、粒度，过于频繁及细节的沟通会导致模块间的强耦合，取而代之会更去强调各团队自己去思考我作为某某模块的开发团队我要提供什么服务。这一点可能与大家的认知会有比较大冲突，我们再拿上面短信的例子来说：业务团队会告诉短信团队我们要这个那个功能，如果两个团队走得比较近，很可能短信团队就不会去思考这功能是不是属于我短信服务应该做的？这个功能能不能再抽象成更通用的服务？相应的功能我们有异步的接口了，它要同步接口是否合理？……像笔者现在带的公共服务团队，我要求我们团队的各个项目组都明确一点：我们是提供公共化服务的，我们要支撑各业务线的通用化需求，但不去迎合其它团队，不要去关心业务细节，不要接个性化需求，只有这样才能保证服务独立、产品解耦。

康威定律实际上讲的是人性、社会关系、组织形态对产品架构的影响，这也在我们大量的实践中得到了验证。所以如果大家做微服务架构，那么务必确保是由多个团队参与的，团队间最好相对独立，定义好边界及服务接口后各司其职，控制好跨团队间的沟通，不要出现“老好人”去破坏团队的独立性及服务边界。微服务化不仅仅是技术架构的变化更需要项目管理、团队成员观念的改变与适应，而这却是很多管理员所忽视的，很多微服务的项目结果都不怎么好，可能不是用的架构师或开发团队有问题而是管理者、领导者自身的管理风格问题。