转载

微服务不是终点站

【编者的话】本文作者讨论了在企业内部该如何落地微服务，重点讲述了企业文化建设的重要性

所谓微服务指的是一些由API驱动的小型应用程序，它们在追求一个共同目标的前提下负责把一件事情做好。

该定义总结了微服务当下最流行的常见说法。再者，如果处理得当的话，微服务真的可以做到它们想要做到的所有美好的事情。从架构和程序的角度来说，相比于更加单体化的方案而言，微服务在应用开发方面拥有许多有意义的优势。看看那些像Amazon和Netflix这样成功的企业，发现自己有这样的想法也就很合情合理了，"微服务！一定是它！"

不过，我并不是很喜欢这个松散的定义，因为它完全忽略了构建微服务背后的一个关键动机：让团队能够更快地交付功能到生产环境，并且摩擦变得更少。微服务只有在正确的软件文化到位时才能发挥最大效果。一个关注微服务的组织也应该像重视开发和运维生产力那样接受并实现一些文化方面的重大转变。

从整体层面考虑，这里有三个严峻的事实是那些正在调研或实现微服务的组织需要考虑的。而且，不出所料，每个事实都更多关注在人和文化方面，胜过工具或者架构。

除非你是一家以持续增长的名义有动力去吸引和留住优秀人才的公司，否则你无法做好微服务。你的目标不一定像 Facebook 大约在2009年那样地高速成长，但是你确实需要一个真正的决心，持续发展业务，并且能够欣赏优秀的软件人才，让他们有用武之地；
在一个走下坡路的背景下，员工还挣扎在生存线的话，你将无法做好微服务。生存主义是一种能够扼杀微服务本应会带来的灵活性和风险性的环境，而且它会积极地劝退那些最有才华的员工。天才的软件构建者们是一群渴望尝试和探索新的最佳实践的人，而不是去学习什么该做，什么不该做；
如果你打算将所有最优秀的开发人员"晋升"到管理岗，那么你（也许）无法做好微服务。微服务架构是由一些超级增长公司设计和推广流行的，这些企业优先考虑的是工程化，这就意味着微服务需要的是有才华的并且熟练这块技能的人才致力于这方面的工作。如果你为他们提供的职业发展机会是技术通道，而非管理通道，他们之中的一些人将可以和你的业务一起快速发展。

在尝试推广微服务时，接受并解决与文化衰退和增长缓慢相关的问题的公司将会好很多。这就是原因所在。

在一些高速增长的企业里，人就是流程

微服务的神话里有一个源自于Amazon和Netflix的传奇故事。这是世界上最有价值并且在当时也是发展最快的两家公司，他们在采用新架构和基础架构模型方面的领导地位有助于向世界传授构建云原生应用程序的意义所在。但是，当我们现在回过头来考虑Amazon和Netflix为什么在微服务上下这么大赌注背后的动机时，我们开始看到一副更详细的画面，讲述了他们为何能够成功转变。一个很大而未被充分认识的因素便是熟练的开发人员在松耦合和个人自治的环境里能够更快成长。

集中式架构将不可避免地发出一些我称之为文化超速罚单的东西 - 在一个单体软件项目中试图按时交付功能时所产生的缺陷的结果。有才华的开发人员会试图通过创新和向管理层提出想法来避免这些问题，这有助于保护他们的自由，自主性和研发速度。Amazon和Netflix的微服务并不是商业计划的一部分。它们是软件工程师和运维人员最终找到的一种减少浪费的方式，并且帮助他们以一种更快，更安全的开发速度构建和运维应用程序 - 没有超速罚单。

对于许多人而言，在一家高速发展的企业里一个很能引起共鸣的反例就是Initech，这是一部另类经典电影 Office Space 中的虚构雇主。主角就是软件开发人员，他们因缺乏自由和自主而受到扼杀。他们受到焦虑和粗心的困扰，因为他们处在生存模式 - 试图在一家重视流程甚于人的企业里继续努力工作（或至少要玩的开心）。一些管理顾问不断涌入并且要求他们削减成本，这让公司的员工感到恐慌，他们觉得有必要为自己的存在辩护。在现实世界中，就像在电影里那样，这种情况下员工和雇主通常都不会满意。

很多时候，今天的软件开发领域同样分成两路派系：高增长的科技公司和其他所有人。微服务的广泛采用有可能帮助填补这一差距，但是前提是采用微服务的公司是出自合理的缘由做出的改变。改善软件架构的最佳途径是首先解决公司的文化问题 - 特别是当这种文化会导致微服务发展停滞，而让员工陷入生存模式的一些历史遗留流程还会成为拦路虎。

每个人都想要自由，效率，以及可控

不过，微服务往往停留在想的阶段，部分原因是一些历史遗留的软件实践可能会导致止步不前的文化氛围。开发人员一直希望的是无需和运维沟通，可以更自由地自动化基础架构，而运维人员则希望的是更自由地自动化基础架构的管理 - 主要是为了防止开发人员不断变更导致业务中断。这些需求源自于管理单体应用程序的共享基础架构时固有存在的困难。

对这种架构的每次变更都是对系统稳定性的一次考验。每道护栏都是变更的障碍。在这种软件文化中，得罪人是一种常态，一个人的粗心大意可能导致其他人在周末时间帮忙收拾残局。因此，他们对于像微服务这样的事物的渴望始终存在。得益于云原生和开源工具的出现，业内不断涌现出性价比更高，更自动化的基础设施，让微服务的部署变得更加容易（如果你想要一些关于如何工作在上云之前的革命故事，我有很多可以分享的），但是，改变文化的困难和费用仍然是主要障碍。

然而，只是可以开始在Kubernetes集群上启动微服务并不意味着你应该急于立马这样做。许多公司没有意识到的是，花在部署上的时间和精力(可能是失败的)，更好是用于首先检查通往生产的路径，并且可以准备将部署流水线做成一个自动化的可重复实践。如果需要几周时间才能把第一行代码部署到生产环境中，那么你应该考虑升级工具，应用一些像持续交付这样的实践。

在将新的复杂度引入架构前，你的出发点应当是为团队提供更轻松、更高效的生活。

微服务不是终点站

图片来源: https://www.slideshare.net/adr ... erlin

试想一下从一个百万行代码的单体应用到500个微服务的转变。这有点像洛杉矶国际机场（LAX）里每个广场只有一个电源插座，成千上万的乘客在大厅里走动，希望找到它并使用它。这样做的话，洛杉矶国际机场也许很快就需要弄清楚该如何从1个出口到其他另外的至少10,000个出口。要解决这个问题，一种方案是购买大量的延长线然后增加插座的数量。这样做的话最终是让电线四处缠绕在走廊里，就像蛇盘绕在飞机上一样，所有都是出自一个插口。没有机场可以做到这一点，但是我们在软件领域往往就是这么做的。

或者它也可以选择做正确的事情：打碎一些墙壁然后把系统重做一下，支持更多的墙壁插座。做正确的事情需要勇气，而且需要自顶向下思考，“如果被绊倒或者争夺单一代码仓库的控制权的人数会因此减少的话，那么打碎一些墙壁是值得的。”