近期，针对“微服务的影响”议题组织了一场InfoQ圆桌直播。该直播的参与者包括：Nginx 解决方案高级架构师 Leif Beaton、独立的 AWS 和无服务器顾问和 Skyscanner 首席工程师Nicky Wrightson。大家共同探讨了运维的复杂性，以及微服务模型的替代方案。
“微 Web 服务”（micro-web-services）一词最早是由Peter Rodgers在 2005 年的“Web 服务前沿大会”（Web Services Edge Conference）上提出的，在当时颇具革命性意义。尽管在 2005 年 SOAP 面向服务的架构正处于顶峰，但 Rodgers 主张的是 RESTful 服务。Rodgers 在演讲中，给出了一种良好设计的微 Web 服务平台，介绍了它是如何在类 UNIX 调度和流水线中组合 Web 和 REST 服务的底层架构准则，通过面向服务的架构提供灵活性和易用性。
此后历经六年的创新和思考，在 2011 年的五月的一次软件架构研讨会上，与会者根据自身所见所为，冠之以“微服务”一词。在 2012 年春季，社区开始使用“微服务”描述此类架构模式。
对此，James Lewis和Fred George曾做过演讲。Adrian Cockcroft将其称为“细粒度面向服务架构”，并在 Netflix 积极推动此类系统的开发落地。
微服务这一新领域中的其他先行者还包括、Evan Bottcher、Martin Fowler和Graham Tackley等人。在微服务得以命名之前，最早的介绍可追溯为Qcon大会的演讲。
随着 DevOps 的引入，微服务正大步向前推进。DevOps 在团队构建系统方法方面变得越来越流行，尤其是持续部署的系统。
但是，微服务也的确需要付出额外的代价。本文将重点关注此类额外成本，以及是否值得权衡考虑微服务。
Wes Reisz：我最喜欢的微服务定义是由 Adrian Cockcroft 提出的，即“限界上下文（bounded context）中细粒度的面向服务架构”。各位是如何定义微服务的呢？
Reisz：微服务自横空出世以来，历经八年的发展。各位认为微服务当前处于技术采纳曲线的哪个阶段，是早期使用者（early adopt）、早期大众（early majority）、晚期大众（late majority）还是落伍者（laggards）？
Reisz： Nicky，你提到了“组织的”。最初我试图理解微服务概念时，找到了 Martin Fowler的这篇博客文章 。我对下面这幅插图印象深刻：“必须达到如此认识高度，才能运维或运行微服务。” 当前的认识高度如何？比原先更高了，还是更低了？成功运维微服务，需要掌握哪些基础技能？
Reisz： Leif，你认为要达到何种高度才能使用微服务？
Reisz：我们已经在微服务上遇到了一些问题，其中之一就是 Nicky 所提到的复杂性。我认为 CNCF（Cloud Native Computing Foundation，云原生计算基金会）整体上就是一个庞然大物，其中提供了多种多样的可能选择。例如，Kubernetes 的容器网络接口（CNI）就存在 Canal、Flannel、Weave、Cilium 等多种可选的容器联网方案。复杂性当然是微服务中的一个影响因素。此外还存在哪些挑战？
Reisz：Nicky，你谈到了组织成熟度。为什么说组织成熟度是微服务面对的挑战之一？
Reisz：Yan，我们最近探讨过编排，也探讨了在微服务环境中实现相互通信中面对的一些挑战。在此你能否介绍一下服务编排方面存在哪些挑战？
Reisz：你提到了事件驱动架构。我的问题是，事件驱动架构与微服务二者间的关系如何？稍微打断一下，请你多解释一下事件驱动与微服务吗？
Reisz：我们已经讨论了组织和复杂性问题，讨论了服务编排的相关问题。鉴于存在所有这些问题、所有的可选项，以及微服务所涉及的复杂性，我们是否应该回到构建单体应用上？
Reisz：Sam Newman 说过类似于“如可能，尽量构建单体应用”的观点。如果单体应用确实无法满足需求，那么再考虑微服务，没必要无缘无故地引入复杂性。Yan，对此你怎么看？
Reisz：前面我们一直将微服务和单体应用绝对对立，但二者之间也存在一些中间方式，下面我们讨论一下模块化单体应用。例如，将多个 Jar 组合在一起，就构成了模块化单体应用。Yan，你如何看待模块化单体应用这样的中间方式？这是一个自然的发展阶段，还是应该直接转向微服务？
Reisz：正如 Yan 所说，使用正确的工具去做正确的事。假设你开发的应用需面对大量的短暂峰值流量，如何使用微服务应对可能仅持续数毫秒的扩容需求？
Reisz： Nicky，我们知道 Skyscanner 使用了数以千计的微服务，你们是如何解决延迟问题的？
Reisz：针对如何分解单体应用，我们看过一些演讲、论文和技术内容。这些资料宣称导致分解单体应用并转到微服务的原因，在于团队间的不协调或是推进速度等问题。但是我们也看到，诸如 Istio 又将 istiod 的架构转回到更类似于单体应用的事情发生。当出现哪些迹象的时候，我们应该回到单体应用上呢？
Reisz：最后总结一下。这里重提 Leif 的观点，我们选择采用某项技术，不能仅仅因为该项技术是新颖的。我们需要能实际解决问题。Nicky，还有什么补充吗？
Reisz：我非常认同 Yan 强调的“微服务解决的是组织问题，而不是技术问题”。Yan，再补充一下？
嘉宾简介：
Wes Reisz 担任 VMware 平台架构师，是边缘计算平台 Section 的前技术副总。Reisz 曾主持 QCon 旧金山大会，在入职 VMware 之前曾任全球 QCon 所有英语大会的产品负责人、HP Enterprise Systems 的首席架构师，并在路易斯维尔大学担任兼职教授达 13 年。此外，Reisz 一直联合主持InfoQ Podcast。
Leif Beaton 是位于爱尔兰 Cork 市的 NGINX 公司的高级解决方案架构师。他具有 20 年的 IT 部门工作经验，已形成包括安全性、网络、软硬件体系架构以及开发在内的多元化背景。Leif 日常工作是与 NGINX 客户互动，为将客户需求转换为现代架构提供帮助。
Yan Cui 是一位经验丰富的工程师，自 2009 年以来一直任职于 AWS。他是银行、电子商务、体育流媒体和移动游戏等多个行业的架构师和首席开发人员。Cui 以其在 Medium 上的无服务器文章以及个人博客theburningmonk.com而闻名。他的部分工作已纳入 AWS 无服务器优选架构白皮书（Serverless Well Architected）。他具备 C＃、F＃、Scala、Node.js 和 Erlang 等语言的专业编程能力。
Nicky Wrightson 具有丰富的大规模云原生架构交付经验。她曾任职《金融时报》，现就职于 Skyscanner。她专注于推动可操作性为大型分布式系统开发的头等问题。运维 Skyscanner 的超大规模数据平台，意味着在整体解决一整套新问题的同时，仍需要尽力实现可操作性、成本效益和可维护性。
原文链接：
Reviewing the Microservices Architecture: Impacts, Operational Complexity, and Alternatives
