前言作者2013年加入ThoughtWorks，工作4年。在这4年里，我以开发人员、DevOps工程师、DevOps顾问、微服务架构师、微服务顾问的身份参与了总共7个产品和项目的微服务咨询和实施。其中，有成功，有失败，有反思，更多的是学习和总结。以下是本人多年来从事微服务咨询的心得总结，希望能给陷入微服务实施困境的小伙伴们带来一些帮助。难点一：“一步到位”的认知错觉让微服务在近几年大行其道，但真正能够作为实际案例使用的却寥寥无几。大多数微服务案例只能看到微服务架构的“演进结果”，而看不到它的“演进过程”。就像每个人都可以看到一座建筑高峰，但看不到攀登它的路径。这就造成了一种错觉：微服务的架构是由能力很强的架构师一步设计出来的。这和很多团队自上而下的架构设计很相似。于是，架构师蜂拥而至，各种分析方法论层出不穷，讨论分享不断。但真正实现的却寥寥无几，使得微服务逐渐成为互联网上的一种“玄学”：微服务的实现一直处于“理论研究”阶段。这违背了软件架构最基本的规律：架构是通过解决当前的需求和痛点来演进的，不能根据没有出现的问题和痛点来设计。因此，一步到位的整体微服务架构设计是完全没有必要的。而且，集中式设计很难体现微服务的轻量化优势。我认为技术必须朝着不断降低成本的方向发展。如果新技术没有降低成本反而增加了成本，要么新技术有问题，要么姿势不对，要么走错了路。因此，准备实施微服务必须要有长期的思想准备。但是在超过初始阈值之后，可以复制其余的工作，而且速度会越来越快。难点二：“架构师精英主义”很多产品对架构师的依赖度很高，即“架构师精英主义”：认为只有这种组织的“技术精英”——架构师才能完成产品架构，而团队其他成员只需要实施建筑师的设计。这是大企业、大系统的通病，源于长期以来重量级企业级架构的习惯。微服务类似于一场“敏捷边际革命”：一种轻量级的架构，可以由不超过2到8人的小团队完成。而对于这样规模的团队，即使将整个微服务团队从产品团队中剔除，也不会影响整个产品的开发进度。所以，就算失败了，也不会带来太大的损失。但是，当第一次微服务改造成功后，成功经验的复制带来的事半功倍的效果可以带来很大的收益。从结构转型投资的风险收益比来看，这是非常划算的。所以微服务团队没必要大做文章，两三个人就可以开工。但是，没有人对微服务有实践经验。如果失败了怎么办？这就带来了下一个困难。难点三：缺乏信任和鼓励创新的环境面对未知领域，失败在所难免。在这个充满不确定性的世界里，成功与失败不再重要：也许今天的失败将被视为明天的成功，反之亦然。成功只是说明结果符合自己假设的预期，失败只是说明结果不符合假设的预期。但无论成败，我们都可以在行动的过程中学习和反思，而这样的经验才是研发活动中最宝贵的。然而，在很多组织中，尤其是“精英”产品团队，职责和压力往往是自上而下分解的。由于组织规模庞大，金字塔结构倾向于建立一个基于“不信任”的体系。这个系统创造了一种“宁可什么都不做也不愿犯错误”的文化。由于失败需要上层负责，所有的创新只能停留在上层，难以实施和推广。在这种情况下，组织的长期合作形成了稳定的工作习惯和心态，形成了利益平衡，这会使整个组织在面对创新时“卡壳”。当微服务作为政治任务自上而下调度时，为了避免失败，团队会互相指责。通过不断的分析、讨论和设计来论证这件事情的难易程度。在我看来，只要你想做，就必须想办法，而不是想象一堆你还没有遇到的问题和责任。在旅途中解决问题比设计和讨论更有效率。组织解决“卡壳”的方法是引入“后备人”：比如新聘请的架构师或外部顾问来完成这件事情。如果出现问题，您不必自己承担责任。这虽然是解决问题的折中办法，却能让事情顺利进行。但这是短期效应，无法解决组织自身的创新困境。长期依赖外力去解决最有价值的问题，不仅不会提升自身，反而会形成对外力的依赖。对于一个有凝聚力的组织来说，这不是一件好事。只有打破目前的工作习惯和思维方式，充分认识创新的困难、风险和价值，才能占领创新高点，吸引人才。难点四：微服务技术栈的“选择难”是由于“精英主义”架构师需要承担很大的责任和压力。他们必须谨慎选择微服务架构的技术栈。因此，我们会在不同的技术栈之间不断尝试。对于习惯于在大型研发机构“精心设计，加班生产”的架构师来说。“长设计，慢反馈”的节奏似乎是理所当然的。微服务开源社区的快速发展催生了“架构师焦虑症”：如果你采用落后的技术，你会被同行、不懂技术的老板甚至下属鄙视。因此，架构师厌倦了在各种新技术堆栈之间进行比较和学习。此外，对技术的不熟悉往往会增加风险，架构师需要更多时间进行研究。带着“一步到位”的架构幻想，精挑细选微服务技术栈，而不是使用现有的低成本方案快速迭代地解决问题。微服务的核心是利用“规模小、反馈快”的机制，通过虚拟化和自动化技术，降低软件系统的复杂度，分散风险，及时应对市场变化带来的各种挑战，进行快速的销售创新，获得市场认可。反馈。不仅仅是利用新兴的语言、编程框架或工具。学习和实践是相辅相成的过程，在实践中学习，将所学知识应用到实践中。这不像准备考试：停下来学习，然后在准备好时全力以赴。以上四点会让大型组织在微服务的实施中“卡壳”，往往导致微服务实施中忽略了最重要的一点，这也是我认为的核心点。难点五：高估微服务的技术变革，却低估微服务带来的组织变革作为架构师，永远不要低估康威定理的威力：“设计系统的组织，它产生的设计和架构等同于沟通组织之间的结构。”从制度经济学的角度来看，软件产品本身就是企业内部组织（员工）与外部组织（用户）之间沟通系统的计算机程序表达。这个系统一定会朝着降低组织内部和外部沟通成本的方向发展。因此，系统架构必须与组织结构保持一致。如果不匹配，势必会阻碍组织的循序渐进。由此得出一个推论：如果企业组织的架构不完善，那么微服务的架构方案也不完善。当架构和组织结构保持一致时，一切都会顺利进行。否则，会出现各种问题。这种关系就像鞋子和脚的关系。只有穿对了鞋，才能走得舒服。太大或太小的鞋子都不会让你跑得更快。当然，你也可以选择买不太合脚但还过得去的鞋子（介绍产品），换鞋的时候只需要停下来试一下即可。也可以高价为自己定制一套。这不会让你在短时间内走得更快，只会让你更健康。如果大家都穿了新鞋，跑得很快，而你却不行，那这不是鞋子的问题，而是脚的问题，不是换鞋就能解决的。得先解决脚的问题，再看鞋子的问题。当然，你也可以用鞋子来矫正脚，虽然会费点功夫，但肯定比不断换鞋要有效。不幸的是，大多数组织还没有为微服务架构带来的组织变革做好准备。“系统架构问题”和“组织问题”还是分开两个不同的领域：微服务是技术问题，组织问题是管理问题。有竞争力的组织，是能够通过整合优势，达到1+1>2效果的组织。与其分散优势，不如让1+1<=2组织。因此，技术问题和管理问题不是两个问题，而是同一个问题的两个方面。因此，如果你的组织结构是去中心化的小团队结构，那么不用担心，你的应用架构会朝着组织结构的方向演进。反之，如果你不是去中心化的小团队结构，那么微服务架构就会与组织结构格格不入。如何解决这些问题？作为微服务的实践者，微服务不应该是“叶公喜龙”，只停留在讨论层面。相反，采用敏捷和精益的方法来快速启动并解决问题。每个组织的组织和业务结构都不同，实施微服务的挑战也大不相同。在实施过程中快速学习和改进，无需长期的整体设计。
