吴佳兴 译 分布式实验室
所谓微服务指的是一些由API驱动的小型应用程序，它们在追求一个共同目标的前提下负责把一件事情做好。
该定义总结了微服务当下最流行的常见说法。再者，如果处理得当的话，微服务真的可以做到它们想要做到的所有美好的事情。从架构和程序的角度来说，相比于更加单体化的方案而言，微服务在应用开发方面拥有许多有意义的优势。看看那些像Amazon和Netflix这样成功的企业，发现自己有这样的想法也就很合情合理了，“微服务！一定是它！"
不过，我并不是很喜欢这个松散的定义，因为它完全忽略了构建微服务背后的一个关键动机：让团队能够更快地交付功能到生产环境，并且摩擦变得更少。微服务只有在正确的软件文化到位时才能发挥最大效果。一个关注微服务的组织也应该像重视开发和运维生产力那样接受并实现一些文化方面的重大转变。
从整体层面考虑，这里有三个严峻的事实是那些正在调研或实现微服务的组织需要考虑的。而且，不出所料，每个事实都更多关注在人和文化方面，胜过工具或者架构。
除非你是一家以持续增长的名义有动力去吸引和留住优秀人才的公司，否则你无法做好微服务。你的目标不一定像Facebook大约在2009年那样地高速成长，但是你确实需要一个真正的决心，持续发展业务，并且能够欣赏优秀的软件人才，让他们有用武之地；
在一个走下坡路的背景下，员工还挣扎在生存线的话，你将无法做好微服务。生存主义是一种能够扼杀微服务本应会带来的灵活性和风险性的环境，而且它会积极地劝退那些最有才华的员工。天才的软件构建者们是一群渴望尝试和探索新的最佳实践的人，而不是去学习什么该做，什么不该做；
如果你打算将所有最优秀的开发人员“晋升"到管理岗，那么你（也许）无法做好微服务。微服务架构是由一些超级增长公司设计和推广流行的，这些企业优先考虑的是工程化，这就意味着微服务需要的是有才华的并且熟练这块技能的人才致力于这方面的工作。如果你为他们提供的职业发展机会是技术通道，而非管理通道，他们之中的一些人将可以和你的业务一起快速发展。
在尝试推广微服务时，接受并解决与文化衰退和增长缓慢相关的问题的公司将会好很多。这就是原因所在。
在一些高速增长的企业里，人就是流程
集中式架构将不可避免地发出一些我称之为文化超速罚单的东西——在一个单体软件项目中试图按时交付功能时所产生的缺陷的结果。有才华的开发人员会试图通过创新和向管理层提出想法来避免这些问题，这有助于保护他们的自由，自主性和研发速度。Amazon和Netflix的微服务并不是商业计划的一部分。它们是软件工程师和运维人员最终找到的一种减少浪费的方式，并且帮助他们以一种更快，更安全的开发速度构建和运维应用程序——没有超速罚单。
对于许多人而言，在一家高速发展的企业里一个很能引起共鸣的反例就是Initech，这是一部另类经典电影Office Space中的虚构雇主。主角就是软件开发人员，他们因缺乏自由和自主而受到扼杀。他们受到焦虑和粗心的困扰，因为他们处在生存模式——试图在一家重视流程甚于人的企业里继续努力工作（或至少要玩的开心）。一些管理顾问不断涌入并且要求他们削减成本，这让公司的员工感到恐慌，他们觉得有必要为自己的存在辩护。在现实世界中，就像在电影里那样，这种情况下员工和雇主通常都不会满意。
很多时候，今天的软件开发领域同样分成两路派系：高增长的科技公司和其他所有人。微服务的广泛采用有可能帮助填补这一差距，但是前提是采用微服务的公司是出自合理的缘由做出的改变。改善软件架构的最佳途径是首先解决公司的文化问题——特别是当这种文化会导致微服务发展停滞，而让员工陷入生存模式的一些历史遗留流程还会成为拦路虎。
每个人都想要自由，效率，以及可控
对这种架构的每次变更都是对系统稳定性的一次考验。每道护栏都是变更的障碍。在这种软件文化中，得罪人是一种常态，一个人的粗心大意可能导致其他人在周末时间帮忙收拾残局。因此，他们对于像微服务这样的事物的渴望始终存在。得益于云原生和开源工具的出现，业内不断涌现出性价比更高，更自动化的基础设施，让微服务的部署变得更加容易（如果你想要一些关于如何工作在上云之前的革命故事，我有很多可以分享的），但是，改变文化的困难和费用仍然是主要障碍。
然而，只是可以开始在Kubernetes集群上启动微服务并不意味着你应该急于立马这样做。许多公司没有意识到的是，花在部署上的时间和精力（可能是失败的），更好是用于首先检查通往生产的路径，并且可以准备将部署流水线做成一个自动化的可重复实践。如果需要几周时间才能把第一行代码部署到生产环境中，那么你应该考虑升级工具，应用一些像持续交付这样的实践。
在将新的复杂度引入架构前，你的出发点应当是为团队提供更轻松、更高效的生活。
试想一下从一个百万行代码的单体应用到500个微服务的转变。这有点像洛杉矶国际机场（LAX）里每个广场只有一个电源插座，成千上万的乘客在大厅里走动，希望找到它并使用它。这样做的话，洛杉矶国际机场也许很快就需要弄清楚该如何从1个出口到其他另外的至少10,000个出口。要解决这个问题，一种方案是购买大量的延长线然后增加插座的数量。这样做的话最终是让电线四处缠绕在走廊里，就像蛇盘绕在飞机上一样，所有都是出自一个插口。没有机场可以做到这一点，但是我们在软件领域往往就是这么做的。
或者它也可以选择做正确的事情：打碎一些墙壁然后把系统重做一下，支持更多的墙壁插座。做正确的事情需要勇气，而且需要自顶向下思考，“如果被绊倒或者争夺单一代码仓库的控制权的人数会因此减少的话，那么打碎一些墙壁是值得的。”
新架构需要新文化
那么要怎么实现呢？以下是一些可以上手推动软件文化改变的事项：
鼓励员工，激励他们采用新的解决方案并且最大限度地降低犯错风险来解决问题。
使用黑客马拉松或其他类型的自由思考练习来增强创造力。
通过试验结对编程等实践来改善协作。
通过在办公室里公开采购一些内部工具和开办会议来建立社区和参与感。
通过举办技术讲座向员工们表达你对他们创造力的重视，他们可以分享衍生项目或其他技术兴趣。
通过启动绿地项目试验新的技术和软件实践。
通过聘请更多元化的团队，寻找新的想法和观点。
如果你经常做上述这些事情，那么你就像是一家为微服务做好准备的企业——因为你正扮演一家想要吸引并留住所需的人才来保持增长的企业。
重要的是要记住微服务不是终点站。对于寻求在软件主导的世界中生存的数字业务而言，微服务只是星辰大海的一部分。升级您的文化与升级您的工具一样重要。
原文链接：https://content.pivotal.io/intersect/microservices-are-not-your-destination
