难点1：“一步到位”的认知错觉

这些年微服务大红大紫，但真正能够拿出来作为可实践的案例少之又少。大部分微服务案例只能看到微服务架构的“演进结果”，但看不到“演进过程”。这就像每个人看到一个架构的高峰，却没有看到攀登高峰的路径。

这给了很多架构师一种假象：为服务的架构是通过能力极高的架构师一步到位设计出来的。这和很多团队自上而下的架构设计感受相似。于是很多架构师们蜂拥而至，各种分析方法层出不穷，讨论和分享络绎不绝，然而真正落地的却很少，使得微服务在网络上慢慢变成了一种“玄学”：微服务实施在“理论研究”的阶段。

这违反了软甲架构的最基本规律：架构是随着当前的需求和痛点演进的，无法对没有出现的问题和痛点进行设计。因此，一步到位的整体式微服务架构设计完全没有必要。况且一个集中化的设计，很难体现微服务的轻量级优势。

我相信技术的发展一定是向不断降低成本的方向上发展的。如果新技术没有降低成本，反而提升了成本，要么这个新技术有问题，要么一定是方法不对，走错了路。因此，准备实施微服务一定要有一个长期的思想准备。不过跨过了最初的门槛之后，剩下的工作可以被复制而且速度会越来越快。

难点2：“架构师精英主义”

很多产品对架构师依赖很大，即“架构师精英注意”：认为产品架构只有这个组织的“技术精英”——架构师才能完成，其他成员只需要实现架构师的设计就可以。这是大型企业和大型系统的常见问题，来源于长期的重量级企业架构的习惯。

微服务类似于一种“敏捷边际革命”：即由一个不超过2~8人的小团队就可以完成的功能。而且这种规模的团队即使从整个产品团队移除也对整体产品的研发进度没有影响。因此，即使失败了也不会带来太多的损失。不过，当第一个微服务改造成功，那么成功经验的复制带来的乘数效应却能带来很大的效益。从架构改造的投资风险收益比来看，这是非常划算的。因此，微服务团队完全没有必要大张旗鼓，只需要两三个人就可以动工。但是，谁也没有微服务的实践经验啊，万一失败怎么办？这就带来了下一个难点。

难点3：缺乏一个信任并鼓励创新的环境

面对未知的领域，失败在所难免。面对这个不确定性频发的世界，成功和失败往往不再重要：也许今天的失败就是明天的成功，反之亦然。

成功只是表明结果符合自己的假设预期，而失败仅仅意味着结果不符合预期。但无论成败，我们都能从行动的过程中有所学习和反思，而这样的经验才是研发活动中最有价值的东西。

然而，很多组织，尤其是“精英主义”的产品团队，责任和压力往往自上而下分解。由于组织庞大，金字塔结构往往会构建一种以“不信任”为基础的制度。这种只读往往营造了一种“宁可不作为，也不能犯错”的文化。由于上层需要对失败负责，使得任何创新只是一个停留在组织上层的想法，难以落实推进。在这种情况下，组织的长期合作形成了稳定的工作习惯和思维定势，并形成了利益平衡，这会使得整个组织在面对创新的时候“卡壳”。

当微服务以一种政治任务从上而下派发的时候，为了避免失败，团队内会互相推诿。通过不断的分析讨论和设计来论证这个事情的难度。在我看来，只要想搞，就一定能找到办法，而不是先设想出一堆含没有遇到的问题和责任。在行动中解决问题是比设计和讨论更加有效率的方法。

而组织解决“卡壳”的办法就是引入“背锅侠”：例如聘请新的架构师或者外部咨询师，来完成这个事情。除了问题就不用自己承担责任了。这样虽然是解决问题的一种折中办法，但可以让事情毫无风险的执行下去。但这是一种短期效应，无法解决组织本身的创新窘境，长期依赖外部力量来解决最优价值的问题不会让自己提升，反而形成了对外部力量的依赖。对于组织的凝聚力来说不是一件好事。

只有打破当前的工作习惯和思维定势，充分认识到创新的困难、风险以及价值的组织才可以占领创新的高点，吸引人才。

难点4：微服务技术栈的“选择困难症”

由于“精英主义”的架构师往往要担负很大的责任，并承担很重的压力。他们必须为微服务架构选择技术栈。因此会在不同的技术栈之间不断尝试。对于习惯了在大型研发组织里“精心设计，加班生产”的架构师而言。“长设计，慢反馈”节奏似乎理所当然。

微服务开源社区的快速发展滋长了“架构师焦虑”：如果采用落后额技术会被同行鄙视，被不懂技术的老板鄙视，甚至被下属鄙视。因此架构师们疲于在各种新型的技术栈之间比较和学习。此外，不熟悉技术往往会增大风险，架构师就需要更多的时间研究。带着“一步到位”的架构幻想对微服务技术栈精挑细选，而不会采用现有低成本的方案快速迭代解决问题。

微服务的核心在于采用“小规模，快反馈”的机制降低软件系统的复杂性并通过虚拟和自动化技术分散风险，从而可以快速面对市场变化带来的各种挑战，并能够快速销售创新，获得市场反馈。而不仅仅是利用到了时下新兴的语言、编程框架或者工具。

学习和实践是相辅相成的过程，在实践的时候学习，并把学习到的知识应用到实践中。而不是准备一场考试，先停下来学习，准备好了再全力以赴。

以上四点会让大型组织面对微服务实施时“卡壳”，而这往往导致微服务实施容易忽略的最重要的一点，我也认为是最核心的一点。

难点5：对微服务的技术变革估计过高，而对微服务带来的组织变革估计不足

作为架构师，永远不要低估康威定理的威力：“设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。”

从制度经济学的角度上讲，软件产品本身就是企业内部组织（员工）和外部组织（用户）沟通只读的计算机程序表达。这个制度的发展一定是在不断缩小内部组织之间以及内外部组织之间的沟通成本的。因此，系统的架构一定是和组织的架构相吻合的，如果不吻合，势必带来问题阻碍组织的渐进。这就引出了一个推论：如果企业组织的架构不是唯一的，那么微服务的架构访问也不是唯一的。

当架构和组织结构相一致的时候，一切都会很顺畅。反之，就会出现各种问题。这个关系就像鞋和脚的关系，只有穿上合适的鞋，走起路来才会舒服。过大过小的鞋都不会让你加快前进的步伐。当然，你可以选择买鞋（引入产品），虽然不是很合脚，但是还可以凑合穿。但是在换鞋的时候，你不得不停下来试试。你也可以花高价为自己定制一套，只不过，这个不会让你走得更快，只会越来越合脚。

如果所有人穿上新鞋，都能跑的很快。那么这就不是鞋的问题，而是脚的问题，这就不是换鞋能解决的了。你得先把脚的问题解决了，然后再看鞋的问题。当然，也可以通过鞋来矫正脚，只不过会花些功夫，但一定会比不停换鞋更加有效。

很不幸，大多数组织并没有准备好迎接微服务架构带来的组织变化。仍然吧“系统架构问题”和“组织问题”割裂成不同领域的问题：微服务是技术问题，组织问题是管理问题。有竞争力的组织，是一个通过融合优势达到1+1>2的组织，而不是把优势割裂开，得到1+1<2的组织。因此，技术问题和管理问题并不是两个问题，而是同一个问题的两个侧面。

因此，如果你的组织结构是去中心化的小团队结构，那么不用担心，你的应用架构会朝组织架构的方向演进；反之，如果你不是一个去中心化的小团队结构，那么微服务的架构会和组织架构格格不入。

那么如何高效推动微服务架构演进呢？请阅读微服务架构落地实践（中）