【.com速译】小是软件领域永恒的主题：团队越小，代码越小，版本越小，代码驻留和执行的环境（容器）越小。变小的目的是让您的企业充分利用云资源，更快地为客户和用户带来更多价值，并着眼长远。微服务是这一趋势的最新标志，它远离在云中运行不佳的单一应用程序。微服务背后的理念对于在云中运行应用程序非常有意义。通过将您的应用程序分解成越来越小的部分，您可以支持敏捷性、按需扩展和频繁更新。与批量转移或更改整个应用程序相比，更改、更新或移动应用程序的小部分更容易且风险更小。这也意味着用户很少知道您何时更新您的应用程序，因为更新总是以最小的方式完成。干扰很小，并且可以快速纠正错误。许多小型独立团队管理应用程序的各个部分，这与高效的DevOps方法是一致的。最后，首席信息官们知道，简单地将遗留应用程序迁移到云端的经济效益有限。只有重新构建应用程序以充分利用云的分布式弹性及其在数据库、存储和分析等不同领域带来的众多服务，公司才能真正节省资金。一切都很好，不是吗？好事太多就是坏事太多？问题是，微服务很快就会不堪重负。突然之间，您有一小段代码只关心支持特定业务流程的一小部分功能。这是开发团队在应用程序中构建了太多微服务，而实际上越简单越好。编排和管理所有服务以协同工作以使应用程序可靠、安全地运行是一项挑战。微服务仍然具有与大型应用程序相同的基础设施需求：备份和恢复、监控、网络和日志记录。这就是称为服务网格的新概念发挥作用的地方。服务网格不断演变的角色当您致电当地市政府时，接线员会迅速将您连接到正确的部门来回答您的问题。服务网格以类似的方式工作：该技术驻留在网络上，处理微服务之间的所有连接，并促进对许多共享服务和工具的访问，例如服务发现、故障检测/恢复、负载平衡、加密、日志记录、监测和验证。这使您的开发团队可以将时间和精力集中在服务本身上，而不是编写代码或逻辑来发现所有服务并与它们建立物理网络。服务网格处理所有联系。服务网格正在迅速成为容器管理的必要技术。它减少了开发人员的工作量，因此他们无需担心容器之间的所有依赖关系和连接。开发人员只需使用智能代理或“边车”将容器（和微服务）连接到服务网格。当今流行且常见的服务网格是一种名为Istio的开源技术，它最初由谷歌开发。Cisco、VMware和其他公司正在将Istio嵌入到他们的产品中。其他可用的开源服务网格技术包括HashiCorp的Consul、Linkerd和Envoy。服务网格技术相对较新，但管理它们的工具正在成熟。在部署服务网格之前需要考虑什么？如果您的企业具有很大程度上同质的技术架构，并且需要对服务的连接方式进行细粒度控制，那么服务网格可能不适合。您可能会遇到需要通过这个新的基础架构层进行通信的微服务的延迟问题，因此如果您的应用程序对延迟的容忍度较低，则使用服务网格可能会出现问题。延迟可能产生影响的一个例子是金融服务业；在这个行业，交易需要在微秒内完成；任何增加延迟的事情都会产生负面影响。此外，构建和管理服务网格会带来一定程度的复杂性。例如，在Istio中，您需要为传入的请求定义复杂的规则并决定如何处理请求，还需要管理遥测数据收集、运行网格的可视化、网格的安全性以及运行网格的网络方面。在决定服务网格是否有意义之前，组织必须权衡这些任务的成本。一般来说，应用程序越复杂，对响应时间和不可预测的规模和工作负载的要求就越高，就越有可能需要服务网格。当然，向您的基础架构添加服务网格在某些方面会增加复杂性，但是当您迁移到微服务密集型和云原生应用程序环境时，它会带来显着的回报，从而降低总体管理和维护要求。如果实施得当，服务网格技术可以提高应用程序的速度、性能、灵活性和经济性。原标题：用服务网格简化微服务，作者：ChrisGarvey
