在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用Istio可以解决这些问题。随着规模和复杂性的增长，服务网格越来越难以理解和管理，各种需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及更加复杂的运维，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
Istio提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点改动或不需要做任何改动。想要让服务支持Istio，只需要在你的环境中部署一个特殊的Sidecar代理，使用Istio控制平面来配置和管理代理，拦截微服务之间的所有网络通信。
此外，面向服务的架构（SOA）的企业服务总线（ESB）与服务网格有一些相似之处，在SOA体系架构中ESB对于应用程序服务来说是透明的，这意味着应用程序对它无感知。服务网格可以得到类似的行为，服务网格应该对应用程序透明，就像ESB那样，简化服务间的调用。当然，ESB还包括交互协议的中转、消息转换，或者基于内容的路由之类的事情，而服务网格不负责ESB所做的所有功能。服务网格确实通过重试、超时、熔断提供服务请求的弹性能力，同时也提供服务发现和负载均衡等服务。复杂的业务转换、业务流程编排、业务流程异常，以及服务编排能力等并不属于服务网格的解决范畴。相对于ESB的集中式系统，服务网格中的数据平面高度分布，其代理与应用程序并存，这消除了ESB架构中经常出现的单点故障瓶颈问题。
当然，也需要清楚服务网格没有解决哪些问题，像Istio这样的服务网格技术通常都提供了强大的基础架构功能，可以触及分布式架构的许多领域，但肯定不能解决你可能遇到的每个问题。理想的云架构能从实现的每个层中分离出不同的关注点。
在基础架构的低层，更加关注基础设施，如何提供自动化部署的基础架构能力。这有助于将代码部署到各种平台上，无论是容器、Kubernetes，还是虚拟机等。Istio不会限定你应该使用哪种自动化部署工具。
在更高的业务应用级别，应用程序业务逻辑是企业保持核心竞争力的差异化资产。这些代码资产涉及了包括业务功能单一以及需要调用的服务，以何种顺序执行，如何执行这些服务的交互，如何将它们聚合在一起，以及在发生故障时要执行的操作等。Istio不实现或替换任何业务逻辑，它本身不执行服务编排，也不会提供业务负载的内容转换或者增强，不会针对负载进行拆分或者聚合。这些功能最好留给应用程序中的库和框架来实现。
图1-6是关于云原生应用程序中的关注点分离，其中Istio对应用程序层起支持作用并位于较低级别的部署层之上。
Istio扮演着部署平台和应用程序代码之间的连接角色。它的作用是促进从应用程序中取出复杂的网络逻辑，可以基于作为请求的一部分的外部元数据（例如HTTP标头等）来执行基于内容的路由。也可以根据服务和请求的元数据匹配进行细粒度的流量控制和路由。还可以保护传输和卸载安全令牌验证，或者可以实施服务运维人员定义的配额和使用策略等。
图1-6 云原生应用中的关注点分离
了解Istio的能力，与其他系统的相似之处以及它在架构中的位置，可帮助我们像我们过去可能遇到的有前途的技术那样犯同样的错误至关重要。