【51CTO.com快译】小巧化是软件领域永恒的主旨：团队越小、代码越小、版本越小、代码驻留和执行所在的环境(容器)越小。变小的目的是让贵企业可以从云资源获取最大的优势，更快地为客户和用户带来更多的价值，从而更长远地思考。微服务是远离庞大整体式应用程序的这股潮流的最新代表，这类应用程序在云端运行不畅。
微服务背后的想法对云端运行应用程序大有意义。通过将应用程序分解成越来越小的几部分，你可以支持敏捷性、按需扩展和频繁更新。改变、更新或移动应用程序的小部分要比批量转移或改变整个应用程序容易得多，风险也低得多。这还意味着用户很少知道你何时进行应用程序更新，因为始终以极小的方式来进行更新。干扰极少，错误可以迅速纠正。许多小型独立团队管理应用程序的各部分，这与高效的DevOps方法相一致。
最后，CIO们知道仅仅将遗留应用程序迁移到云端带来的经济效益有限。只有通过重新设计应用程序的架构以充分利用云的分布式弹性以及云在数据库、存储和分析等不同领域所带来的众多服务，公司才能真正省钱。这一切都很好，是不是?
好事过多反成坏事?
问题是，微服务很快变得不堪重负。突然你有了一小段代码，它只与支持某业务流程的一小部分功能有关。这时候，开发团队在应用程序中构建过多的微服务，而实际上越简单越好。
编排和管理所有服务以协同运行以便应用程序可靠安全地运行颇具挑战性。微服务仍与较庞大应用程序对基础设施有着同样的需求：备份和恢复、监控、网络和日志记录。这时候名为服务网格(service mesh)的新概念开始发挥作用。
服务网格的角色在演变
你打电话给当地市政府时，一位接线员会帮助你快速联系上合适的部门来解答问题。服务网格以类似的方式运作：这项技术驻留在网络上，处理微服务之间的所有联系，并便于访问诸多共享服务和工具，比如服务发现、故障检测/恢复、负载均衡、加密、日志记录、监控和验证。这使你的开发团队得以将时间和精力集中在服务本身上，而不是编写代码或逻辑以发现所有服务并与它们进行物理网络连接。服务网格处理所有联系。
服务网络正迅速成为容器管理的必要技术。它可以减少开发人员的工作量，因此他们不需要担心容器之间的所有依赖关系和联系。开发人员只需使用智能代理或“sidecar”，即可将容器(和微服务)连接到服务网格。
今天流行且常见的服务网格是一种名为Istio的开源技术，它最初由谷歌开发。思科、VMware及其他厂商正将Istio嵌入到各自的产品中。其他可用的开源服务网格技术包括HashiCorp的Consul、Linkerd和Envoy。服务网格技术比较新，但管理它们的工具趋于成熟。
部署服务网格前要考虑什么?
如果贵企业的技术架构大体上同质，又需要对服务的联系方式进行精细控制，那么服务网格可能不适合。你可能遇到与需要通过这个新的基础设施层进行通信的微服务有关的延迟问题，因此如果应用程序对延迟的容忍度很低，使用服务网格可能会出问题。延迟可能带来影响的一个例子是金融服务业;在这个行业，交易需要在几微秒内完成;增加延迟的任何因素都可能会产生负面影响。
此外，构建和管理服务网格会带来一定程度的复杂性。比如在Istio中，需要你针对入站请求定义复杂规则，并决定如何处理请求，还要管理遥测数据收集、运行网格的可视化、网格的安全性以及运行网格的网络方面。企业须权衡这些任务的成本，再决定服务网格是否合理。通常来说，应用程序越复杂，对响应时间和不可预测的规模和工作负载等方面的要求越高，需要服务网格的可能性就越大。
当然，为你的基础设施添加服务网格会在某些方面增添复杂性，不过改用繁重的微服务和云原生应用程序环境后，它会带来重大回报，总体上减少管理和维护要求。若实施得当，服务网格技术可以为你的应用程序提升速度、性能、灵活性和经济效益。
原文标题：Simplifying microservices with a service mesh，作者：Chris Garvey
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
