微服务之架构即管理

来，讲故事：

 

单体架构(1)：

 

小蓝创办了一家公司，由于资金紧张，招聘了小白负责行政，小红负责财务，小黑负责技术，小黄负责运营，5个人撸起袖子就是干，准备向市场推一个 “××宝” 的产品。

实际上每个人职责界限都不那么明确，小白忙了小红帮，小红忙了小黑帮，小黑忙了没人帮，小黄不忙到处帮，小蓝组织帮帮帮。

发展中...

 

分布式-面向服务架构(1-10)：

 

尽管问题如此多，但由于团队小而精，小蓝以产品为核心领导着团队还是迅速推出了产品，然后用各种手段验证该产品在市场上有无前景。

果不其然，他们成功了，而且公司还顺利拉到了第一笔融资，准备完善 “××宝” 。

此时公司需要扩张人手来满足当前业务需要，于是扩招到50人，但是小蓝很快就发现自己管不过来了，团队处于一个沟通低效的内耗状态，

于是小蓝根据(DDD领域驱动设计)职能将公司分成4个部门，委任元老小白、小红、小黑、小黄为各部门负责人，分别处理相关业务，情况得以改善。

发展中...

 

分布式-微服务架构(10-100)：

 

在大家的努力下， “××宝” 成功推向市场趋于稳定且有着不错的营收，公司也顺利拿到第二笔融资。

小蓝微微一笑，你以为这样我就满足了吗？跟着我有桃吃，我又看到几个不错的产品方向，故公司计划继续扩张，扩张到500人。

这时候小白、小红、小黑、小黄...也发现自己管不过来了，于是各部门都分成了A组、B组、C组、D组...

问题又来了，x项目需要小白的A组、小红的B组、小黑的C组、小黄的D组...相互配合，大家意识到沟通再次低效了。

于是聪明的BOSS小蓝提出应该成立项目组，让各组可以直接沟通，于是小白、小红、小黑、小黄...商议后，委任数个项目经理分别负责各项目，把控沟通过程及结果，确保团队仍然可以小而精的合作。

发展中...

 

分布式-微服务集群(1-100,1-100...)：

 

随着各产品业务辐射全国，总部心有余而力不足导致用户体验下降，所以总部成立了分公司分别处理华东、华西、华北、华南的业务，来加快对用户反馈的响应速度。

 

 

发展中...

变化中...

发展着变化着...

 

故事，讲完了。

有没有发现架构设计和落地的时候存在着团队管理的问题，团队管理的时候蕴藏着架构设计的哲学？

康威第一定律：组织沟通方式会通过系统设计表达出来。