每个架构师都在研究的康威定律，程序员进阶路上，你思考过吗？( 三 ) _康威定律

架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。下图的DevOps和每日交付是每一个互联网系统架构师的梦想和努力的方向。

文章插图

谈谈微服务架构微服务我想大家都听得很多了，我本人也非常关注和推崇微服务，从技术角度讲，我认为微服务主要体现的是单一职责和关注分离的思想，从单进程模块化进一步拓展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元，正如我在第一点架构定义中提到的，微服务中每个服务可以独立演变，它的cost of change比较小，整体架构比较灵活，是一种支持创新的演化式架构。

文章插图

这个图讲什么时候该引入微服务。微服务有额外成本的，需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑。另外补充一点，微服务更多是关于组织和团队，而不是技术。
架构和组织文化关系再谈一下康威定律：Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)
从单块架构到微服务架构是这个定律的很到体现。

文章插图

团队是分布式的，系统架构是单块的，开发，测试，部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突conflict 。

文章插图

将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。
可见，组织和系统架构之间有一个映射关系（1 ~ 1 mApping），两者不对齐就会出各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功建立高效的系统架构，例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的企业，很难推行微服服务和DevOps，推行Docker/PaaS平台也会比较困难，这样的组织职能之间都倾向于局部优化（local optimization），无法形成有效和合作和闭环。
反过来也是成立的，如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。
架构师心态和软技能空杯，或者说开放心态（open minded）是一个成熟架构师的应有心态，stay hungry, stay foolish，心态有多开放，视野就有多开阔。来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师 :
如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必有我尚未体会的奥秘，值得加以了解。与人合作最重要的是，重视不同个体的不同心理、情绪与智能，以及个人眼中所见的不同世界。与所见略同的人沟通，益处不大，要有分歧才有收获。
另外再推荐一个本书《软件架构师的12项修炼》，这书中三个观点很值得每个架构师学习领会:

soft skills are always hard than hard skills，软技能比硬技能难
choosing relationship over correctness，注重关系重于谁对谁错
架构的政治性，在中大型公司里混的架构师尤其要学习

政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。
架构师如何提升？实战，实战，实战！规划职业，找好的团队和项目，总结分享，学习GitHub开源项目，尽可能参与和开创自己的开源项目和产品，并长期积累。
我对一些架构师争议主题的看法主要争议是两个话题：