回退到2016年，人们写了很多关于“微服务”的，就像1996年一堆“信息高速公路”文章一样。当这个词开始退火，人们开始建设互联网，微服务的 “微”也随着在搭建可扩展的软件系统中服务标准化而消失。这个词在人们所想所用的技术中意味着一种转变。通过基于服务的架构意味着开发者集中在服务之间的连接，这样也能让他们搭建更好更快的软件。

从2016年开始，开发者效率很高是在于每次专注一个服务。什么是服务？基本上就是最小的软件有效片段，可以去简单定义和独立部署。比如通知服务，登陆服务，持久化键值存储服务。一个好的系统不仅仅做一件事，并且做的很给力。开发者可以很快行动，因为他们不需要担心虚拟机或者其他低端的架构：服务建立起抽象层（这也称为无服务的计算）。因为这些服务间的连接是显式的，开发者就自由想象应用作为整体，并把精力放在自己的功能和依赖的服务上。

以前，很多公司觉得转向微服务不就是把一个二进制分割成10个更小的嘛。但他们发现还是有同样的老问题，就是重复了十遍罢了。慢慢他们也意识到搭建可靠应用不是说就是把单一整体分割成小片段，而是去理解各个片段的联系。开始问正确的问题：我的服务依赖什么服务？当依赖者不响应怎么办？还有什么服务会通过RPC（远程过程调用）到我的服务？期待多少RPC？回答这些问题需要新的工具和理念。

工具

搭建基于服务的架构如果没有工具箱是不可能的，需要去理解独立性和服务间的内在特质。程序上使用的工具是，通过API的界限和服务间的关联。他们有效去定义不同服务的交换协议。这些工具也帮助文档化和测试服务，去生成很多在建立分布式应用的管道。

另一个重要工具可以帮助部署和协调服务：把高层服务对应到他们消费的底层资源（并恰当的规模化）的调度器，同时作服务发现和负载均衡去保障请求到达。

最后，当部署一个新应用，第三方的工具帮助开发者理解基于服务的应用行为并帮助隔离问题。回到微服务的早期，开发者失去那种像单一应用的掌控能力。突然间他们不能对一个日志文件去搜索查找根源：现在需要从分布在100个节点的日志，交织1000个其他请求中去找答案。基于多进程的跟踪，聚合关键路径分析，和智能错误切入的先进技术才能让一个分布式系统变的可以理解。

这些工具到2016年也有了，但生态系统还不完善。有少量标准，但新工具需要大量投资，而现有的东西不能一起工作。

新方法

当服务成为每天，每个开发者一种思考方式，部分是因为工具库。但当开发者在做软件时就思考服务第一和重要性，这场革命才刚开始。就像测试驱动的部署意味着开发者在一开始编写他们第一行代码时就得测试，服务驱动的部署意味者服务依赖性，性能监控，和RPC的上下文，这些作为最重要的考虑。

总之，服务（微）是好东西（我们不需要去说“微服务”了，因为这不是靠服务的大小决定的：而是他们之间的连接和关系）。服务重现开始围绕在功能的软件部署，让开发者更快更独立去做他们关心的事情：这就是给用户提供价值！

文 | lightstep