4.1. 团队架构

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

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

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

def result_code send(phone,message)

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

def result_code send(phone,message,channel)

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

def result_code send(phone,templateId,parameters)

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

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

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

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

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

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

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

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

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

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

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

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