http://jiasuhui.com/wp-content/uploads/2016/07/unnamed-file-25.png| 微服务已死？新工具永生！" />

加速会注：这是一篇来自未来的报道，那时候，构建可靠和数量可控的生产系统会变得很简单，像写程序一样。接下来让我们看看，未来是什么样子的…

早在2016年，人们写了很多关于“microservices”的文章，这就像他们在1996年写了很多关于“信息高速公路”一样。“信息高速公路”一词逐渐消失，人们开始建立互联网，微服务的“微”部分也成为构建数量可控的系统的方法。尽管这中技术已经不再使用了，但我们还用这个名称来展示人们的思考方式和技术使用方式是如何转变的。使用基于服务的架构，意味着开发人员可以专注于服务之间的连接，这使他们能够开发更好的软件，并增快开发速度。

信息高速公路的兴衰

自2016年以来，开发人员一直致力于开发一个更有效率的产品。是什么服务呢？总的来说，是用最小的软件来完成任务，这些任务可以被独立运行，也可以简单地被定义和部署，比如通知服务、登录服务或持续的键值存储服务。完整的服务只是一方面，但它在其他方面可以做得很好。开发人员现在的效率更快，是因为他们不用担心虚拟机或其他基础设施：服务水平被提高了。（另一个术语：这叫无服务器计算）因为服务之间的联系是明确的，所以开发人员也不用再整体思考应用程序，而是可以专注于各自的特性和相关的服务。

从前，许多组织认为使用微服务架构就意味着“将一个二进制文件分割为10小的文件”。他们也发现这么做会让同样的老问题重复10次。随着时间的推移，他们意识到，构建一个好用的应用程序不仅仅是将庞然大物份成小块，而是理解这些作品之间的联系。他们的确发现了问题所在：我的服务需要什么服务支持？如果所需的服务不好用，该怎么办？有什么其他服务能让远程过程调用协议为我服务？我可以使用多少远程过程调用协议？想要回答这些问题，需要一套新的方法和思维方式。

软件架构需要新的工具

http://jiasuhui.com/wp-content/uploads/2016/07/unnamed-file-26.png| 微服务已死？新工具永生！" />

如果没有新的工具包来调用独立但相互关联的服务，构建基于服务的架构是不可能的。一组工具以编程的方式描述了服务、定义了API边界和服务之间的关系，也有效地定义了不同服务之间的关系。这些工具还帮助建立文档和测试服务，并生成大量的带有分布式应用程序的模板。

另一个重要的工具也可以帮助部署和协调服务：调度器可以使用高级服务来映射使用的资源（同时会进行调整），同时还会使用服务发现功能和负载平衡器，以确保得到需要的请求。

最后，部署好一个应用程序之后，第三套工具可以帮助开发人员理解基于服务的应用程序的行为，帮助他们了解问题为什么出现。再说到早期的微服务，开发人员失去了很多的可见性，他们已经习惯于独立应用程序。所以他们就不能通过日志文件来找到问题的根源，而现在的方法是将日志文件分割成100个节点，用1000个其他请求进行连接。只有进行多进程跟踪，将关键路径进行分析，智能故障注入系统才能理解到分布式应用程序的行为。

2016年时，有许多这样的工具存在，但生态系统尚未形成，也几乎没有相关标准，所以新工具需要大量投资，因为现有的工具没有很好地协同工作。

软件服务革命正式开始！
http://jiasuhui.com/wp-content/uploads/2016/07/96eca584d8be.png| 微服务已死？新工具永生！" />

这种服务如今很常用，也是开发人员的惯用思维方式，多少都是因为这个工具包。但只有开发人员在构建软件时思考相关的服务，革命才能真正开始。正如测试驱动的开发意味着开发人员在写代码之前就考虑测试事宜，服务驱动开发也意味着服务的依赖性，RPC的环境也会成为性能检测的首要问题（而不只是掩盖问题）。

总的来说，服务（无论是微服务还是其他服务）一直是件好事。（我们不再需要使用“微服务”这个名词了，回想起来，这是因为服务的大小并不重要，服务的连接才重要）。服务再次以软件之间的联系为中心，让开发人员可以工作地更迅速、更独立，做真正重要的事情，即为用户创造价值。

直到现在，在构建生态系统的服务和LightStep方面，还有很多令人激动的工作要做，我们很荣幸成为这场革命的一部分，通过跟踪调查的方式来提高对生产系统的可见性。

本文来自：加速会

原文地址：http://jiasuhui.com/archives/89833