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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。