前言
笔者从2013年加入ThoughtWorks至今共4年时间。在这4年时间里，我分别以开发人员、DevOps工程师、DevOps咨询师、微服务架构师以及微服务咨询师的角色参与了共计7个产品和项目的微服务咨询和实施。其中有成功，有失败，有反思，更多的是学习和总结。以下是我这些年来在微服务咨询上的经验总结，希望能给陷入微服务实施困境的人带来一些帮助。
难点1：“一步到位”的认知错觉
这些年微服务大红大紫，但是真正能够拿出来做为可实践案例的少之又少。大部分的微服务案例只能看到微服务架构的“演进结果”，但是看不到其“演进过程”。这就像每个人可以看到一个架构的高峰，却看不到攀登高峰的路径。
这就造成了一个假象：微服务的架构是通过能力极高的架构师一步到位设计出来的。
这和很多团队自上而下的架构设计感受很相似。于是架构师们蜂拥而至，各种分析方法论层出不穷，讨论和分享络绎不绝。然而真正落地实施的却很少，使得微服务在网络上慢慢变成了一种“玄学”：微服务的实施一直在“理论研究”的阶段。
这违反了软件架构的最基本规律：架构是通过解决当前的需求和痛点而演进的，无法根据没有出现的问题和痛点进行设计。因此，一步到位的、整体的微服务架构设计完全没有必要。况且一个集中化的设计，很难体现微服务的轻量级优势。
我相信技术一定是向不断降低成本的方向发展的。如果新技术没有降低成本反而提升了成本，要么这个新技术有问题，要么是姿势不对、走错了路。
因此，准备实施微服务一定要有一个长期的思想准备。不过跨过了最初的门槛之后，剩下的工作可以被复制、而且速度会越来越快。
难点2：“架构师精英主义”
很多产品对架构师的依赖很大，即“架构师精英主义”：认为只有这个组织的“技术精英”——架构师才可以完成该产品的架构，而团队其它成员只需要实现架构师的设计就可以。这是大型企业和大型系统的常见问题，来源于长期以来重量级企业级架构的习惯。
而微服务则类似于一种“敏捷边际革命”：即由一个不超过2~8个人的小团队就可以完成的轻量级架构。而且对于这种规模的团队而言，即使把整个微服务团队从产品团队移除也不会对整体产品的研发进度产生影响。因此，即使失败了也不会带来太多的损失。不过，当第一个微服务改造成功，那么成功经验的复制带来的乘数效应却能带来很大的收益。
从架构改造投资的风险收益比来看，这是非常划算的。
因此，微服务团队完全没必要大张旗鼓，只需要两三个人就可以动工。但是，谁也没有微服务的实践经验啊，万一失败了怎么办？
这就带来了下一个难点。
难点3：缺乏一个信任并鼓励创新的环境
面对未知的领域，失败再所难免。而处在这个不确定性频发的世界，成功和失败已经不再重要：也许今天的失败，明天再看就是成功，反之亦然。
成功只是表明结果符合自己的假设预期，而失败仅仅意味着结果不符合自己的假设预期。但是无论成败，我们都能在行动的过程中有所学习和反思，而这样的经验才是研发活动中最有价值的。
然而，很多组织，尤其“精英主义”的产品团队，责任和压力往往从上至下分解。由于组织庞大，金字塔的结构往往会构建一种以“不信任”为基础的制度。这种制度营造了一种“宁可不作为，也不能犯错”的文化。由于上层需要对失败负责，使得所有创新只能停留在上层，难以落实推进。在这种情况下，组织的长期合作形成了稳定的工作习惯和思维定势，并形成了利益平衡，这会使得整个组织在面对创新的时候“卡壳”。
当微服务以一种政治任务从上而下派发的时候，为了避免失败，团队内部会相互推诿。通过不断的分析讨论和设计来论证这个事情的难度。在我看来，只要想搞，就一定能找到办法，而不是先设想出一堆还没有遇到的问题和责任。在行进中解决问题是比设计和讨论更加有效率的方法。
而组织解决“卡壳”的办法就是引入“背锅侠”：例如新聘请的架构师或外部咨询师，来完成这个事情。出了问题就不用自己来承担责任了。这样虽然是解决问题的一种折中办法，可以让事情毫无风险的执行下去。但这是一种短期效应，无法解决组织本身的创新窘境，长期依赖外部力量来解决最有价值的问题不会让自己提升，反而形成了对外部力量的依赖。对于凝聚组织来说不是一件好事。
只有打破当前的工作习惯和思维定势，充分认识到创新的困难、风险以及价值，才可以占领创新的高点，吸引人才。
难点4：微服务技术栈的“选择困难症”
由于“精英主义”的架构师需要担负很大的责任和压力。他们必须要为微服务架构谨慎的选择技术栈。因此会在不同的技术栈之间不断尝试。对于习惯了在大型研发组织里“精心设计，加班生产 ”的架构师而言。“长设计，慢反馈”节奏似乎是理所应当的。
微服务开源社区的快速发展滋长了“架构师焦虑”：如果采用落后的技术会被同行鄙视，被不懂技术的老板鄙视，甚至被下属鄙视。因此架构师们疲于在各种新型的技术栈之间比较和学习。此外，不熟悉技术往往会增大风险，架构师就需要更多的时间研究。带着“一步到位”的架构幻想对微服务技术栈精挑细选，而不会采用现有低成本的方案快速迭代的解决问题。
微服务的核心在于采用“小规模，快反馈”的机制降低软件系统的复杂性并通过虚拟和自动化技术分散风险，从而及时应对市场变化带来的各种挑战、进行快速销售创新，获得市场的反馈。而不仅仅是利用到了时下新兴的语言，编程框架或工具。
学习和实践是相辅相成的过程，在实践中学习，并把学习到的知识应用到实践中。这不同于准备一场考试：先停下来学习，准备好了再全力以赴。
以上四点会让大型组织在微服务实施中“卡壳”，这往往会导致微服务实施忽略最重要一点，也是我认为也是核心的一点。
难点5：对微服务的技术变革预估过高，而对微服务带来的组织变革预估不足
作为架构师，永远要不要低估康威定理的威力：“设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。”
从制度经济学角度来讲，软件产品本身就是企业内部组织（员工）和外部组织（用户）沟通制度的计算机程序表达。这个制度一定会朝着缩短组织内外部沟通成本的方向发展。
因此，系统架构一定是和组织架构相吻合的，如果不吻合，势必会阻碍组织的渐进。
这就引出了一个推论：如果企业组织的架构不是唯一的，那么微服务的架构方案也不是唯一的。
当架构和组织结构相一致的时候，一切都会很顺畅。反之，就会出现各种问题。
这个关系就像鞋和脚的关系，只有穿上合适的鞋，走起路来才会舒服。过大过小的鞋都无法让你加快前进的步伐。当然，你可以选择买鞋（引入产品），虽然并不是很合脚，但还可以凑合穿，只是在换鞋的时候你不得不停下来试。你也可以花高价为自己定制一套，这个不会让你在短时间内走得更快，只会越来越合脚。
如果所有人穿上了新鞋，都能跑得很快，只有你不能，那么这就不是鞋的问题，而是你脚的问题，这就不是换鞋能解决的了。你得先把脚的问题解决了，然后再看鞋的问题。当然，也可以通过鞋来矫正脚，只不过会花些功夫，但一定会比不停的换鞋更加有效。
很不幸，大多数的组织并没有准备好迎接微服务架构带来的组织变化。仍然把“系统架构问题”和“组织问题”割裂成两个不同领域的问题：微服务是技术问题，组织问题是管理问题。
有竞争力的组织，是能够通过融合优势达到1+1>2效果的组织。而不是把优势割裂开，让1+1<=2的组织。因此，技术问题和管理问题并不是两个问题，而是同一个问题的两个侧面。
因此，如果你的组织结构是去中心化的小团队结构，那么不用担心，你的应用架构会朝组织架构的方向演进。反之，如果你不是一个去中心化的小团队结构，那么微服务的架构会和组织架构格格不入。
如何解决这些问题？
作为微服务的实践者，对微服务不应该是“叶公好龙”，仅仅停留在研讨的层面。而应该采用敏捷和精益的方式迅速开始，在行进中解决碰到的问题。每个组织的组织结构和业务结构都有所不同，微服务实施所面对的挑战也截然不同。在实施的过程中快速学习并改进，没有必要进行周期较长的总体设计。
关于如何解决本文提到的5个问题，请参考下篇《提升微服务实施效率的7个步骤》。
本文首发于GitChat，原作者顾宇，经作者同意授权转发。转载请联系作者或GitChat。
