当前位置： 软件开发团队架构-互联网运营团队架构
不知道大家有没有观察到：通常系统架构和组织架构都是相似的。 比如在前后端分离的架构中，组织一般分为前端组和后端组； 而在微服务架构中，分组与服务相关，一个组可能负责一个微服务。
事实上软件开发团队架构，组织结构和技术结构相似并非偶然。 这种现象背后有一条定律叫做康威定律。 梅尔文康威博士 1967 年发表的论文“委员会如何发明？”中最著名的一句话。 是：
设计系统的组织被迫生产系统，这些系统是这些组织的通信结构的副本。 — 梅尔文康威
如果翻译这句话，意思是：
您设计的软件系统架构将以某种方式反映软件背后团队的组织结构。 当你设计软件的系统架构时，你也在设计你的组织结构，反之亦然。 也可以简单理解为：组织结构的设计等同于制度结构的设计。
如果你用康威定律来验证你现在的团队组织结构，或者你熟悉的其他团队的组织结构，你会发现运行良好的项目都非常符合这个定律。 那些庞大而复杂的单体软件系统背后也对应着一个庞大的开发团队，而那些应用微服务的项目都在每个团队的背后。
读完康威定律，回过头来看微服务软件开发团队架构，你会发现微服务架构的设计不仅仅是服务拆分的架构设计，更是组织结构拆分的设计。
当你在设计系统架构的时候，考虑到组织结构的设计，很多问题就会迎刃而解。 比如你的开发团队有30个人，你想用微服务架构，拆分成3到5个微服务比较合适。 因为每个组大概有10个人，每个组维护1到3个微服务，这个比例是比较合适的。
那你再看看微服务应用失败的案例。 比如一个小的开发团队如果搭建了一个超过100个微服务的架构，那么团队维护这些服务的成本肯定是相当高的，而且最后维护起来会很吃力。
在一些传统的大型企业中，团队构成是根据工种划分为不同的团队。 一个团队开发，一个测试，一个运维，那么实现微服务的阻力会非常大，因为这样的组织结构和微服务的组织结构是不兼容的。
对于微服务的组织结构，需要按照服务来划分团队。 团队成员包括开发、测试和运维。 他们一起组成一个小团队，围绕服务进行迭代，这样效率最高。
总结
上一篇 
