微服务于10 年前出现，是软件中发生融合进化的例子之一。虽然这个词可以归功于全球软件顾问Thoughtworks 的James Lewis和 Martin Fowler （banq注：这个词应该首先由亚马逊提出，也就是著名“一个披萨”，开发一个微服务的人员正好够吃一个披萨 ，MF只是进行了微服务这个名词详细定义），然后许多其他硅谷公司Netflix 、谷歌和eBay 在大致相同的时间各自独立或多或少实现相同架构模式。
在这个术语被创造出来的十年里，我们看到了 Kubernetes、服务网格和无服务器的兴起，我们也开始看到微服务对前端的影响。除了水平扩展实践，微服务还允许开发人员更快地部署代码，支持组件的可替换性而不是可维护性。
无论好坏，微服务已成为许多人的默认架构选择。对于拥有自治团队和松散耦合系统的组织，微服务可以很好地工作，但它们带来了使用任何分布式系统时固有的复杂性。
考虑到这一点，进入微服务时代的十年后，思考我们已经达到的目标以及我们仍然需要解决的问题是很有趣的。
历史回顾：部署和运行时
现在有各种各样成熟、设计良好的微服务框架，涵盖了大多数语言的基础知识，在 JVM 上有大量选项，包括Spring Boot、Dropwizard、Helidon、Lagom、Micronaut和Quarkus，以及Go等选项用于 Go 的工具包、用于 Python 的Flask和Falcon、用于 JavaScript 的Node.js等等。
同样，良好的监控选项比比皆是。OpenTelemetry的出现尤为重要。它由 OpenTracing 和 OpenCensus 合并而成，拥有广泛的供应商和语言支持，为分布式遥测数据的外观提供标准化。这意味着开发人员只需对他们的代码进行一次检测，然后就可以交换和更改监控工具，比较竞争解决方案，甚至可以在生产中针对不同需求运行多个不同的监控解决方案。
然而，当我们查看部署和运行时，情况变得有点模糊。Kubernetes 或多或少已成为微服务的同义词，但其复杂性日益增加。
Spotify新工程师需要花费60日才能合并他们的第10 pull请求，对此，该公司剥离了开发者门户网站、后台，现在使用沙盒项目封装云本地计算基础。
Netflix非常重视 DevEx，为开发人员“铺平道路”，加速采用GraphQL等新技术。同样，我们已经看到了内部构建和通过像Humanitec这样的供应商构建的开发者平台的兴起。Ambassador Labs有一个与开发人员控制平面相关的概念——它的网站声称，“使开发人员能够控制和配置整个云开发循环，以便更快地交付软件。”
Kubernetes 对开发人员不友好。令我震惊的是，我们仍然没有在 Kubernetes 之上广泛使用的良好、可靠、类似于Heroku的抽象。
未来趋势1：将服务网格隐藏在抽象背后
服务网格被推入更深的平台，并且在很大程度上对开发人员隐藏。例如，红帽 OpenShift在幕后集成了 Istio，并且有多个类似的举措将服务网格与公共云平台更紧密地集成在一起，例如AWS App Mesh和Google Cloud Platform Traffic Director。
还有一些工作以减少服务网格引入的网络开销。一些最有前途的工作是Cilium团队的工作，它利用Linux 内核中的eBPF功能来实现所谓的“非常高效的网络、策略执行和负载平衡功能”。
Ambassador Labs 开发者关系总监认为：我认为现在我们需要为我们其他人提供领域驱动设计。因为即使是普通开发人员而不是架构师也需要对如何确定实体和边界的范围有一定的了解，其中很多都可以追溯到良好的 API 设计。
另一种隐藏服务网格可能性是我们可能会完全转移到不同的运行时：函数为一种服务（FAAS）/无服务器将最终取代Kubernetes作为分布式应用的事实标准运行，我们也看到了一些真实世界的生产实例其中，例如BBC，其 大部分在线架构已从其先前的 LAMP 堆栈直接转向Amazon Web Services上的Lambda。
未来趋势2：面向业务抽象的自治团队架构
Eric Evans 的领域驱动设计是微服务运动的基石，任何软件架构师都应该阅读。但更进一步：即使是普通开发人员而不是架构师，也需要对如何确定实体和边界的范围有一定的了解，其中很多都可以追溯到良好的 API 设计。一旦你理解了耦合和内聚的重要性，关注点和边界的分离，你就会自然而然地投入到你正在处理的任何抽象（模块、类、服务、应用程序）中。
Newman 的书《构建微服务》即将出版的第二版介绍了许多这些概念，并考虑到了下一代服务。
更多点击标题