Istio能做什么?
Istio 试图解决微服务实施后面临的问题。Istio 提供了一个完整的解决方案，对整个服务网格行为洞察和操作控制，以满足微服务应用程序的多样化需求。
Istio在服务网络中提供了许多关键功能：
1、流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
2、可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
3、策略执行：将策略应用于服务间的互动，确保访问策略得以执行，资源在消费者间良好分配。策略更改通过配置网格而不是修改应用程序代码。
4、服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。
除此之外，Istio针对可扩展性进行了设计，以满足不同的部署需要：
1、平台支持：Istio旨在在各种环境中运行，包括跨云， 预置，Kubernetes，Mesos等。最初专注于Kubernetes，但很快将支持其他环境。
2、集成和定制：策略执行组件可以扩展和定制，以便与现有的ACL，日志，监控，配额，审核等解决方案集成。
以上这些功能极大的减少了应用程序代码，底层平台和策略之间的耦合，使微服务更容易实现。
Istio的真正价值
Istio官方列出了很多高大上功能，但这些都不是重点，任何微服务框架只要愿意往上面堆功能，早晚都可以实现这些功能。
那，关键在哪里？不妨设想一下，如果没有Istio这样的服务网格，如何开发微服务引用应用程序，才可以做到前面列出的这些丰富多彩的功能? 这数以几十记的各种特性如何才可以加入到应用程序?
首先，架构师会找个Spring Cloud或者Dubbo的成熟框架，直接搞定服务注册，服务发现，负载均衡，熔断等基础功能。
然后，架构师开发服务路由等高级功能，接入Zipkin等Apm做全链路监控，自己做加密、认证、授权。 想办法搞定灰度方案，用Redis等实现限速、配额。诸如此类，一大堆的事情， 都需要自己做，无论是找开源项目还是自己操刀，最后整出一个带有一大堆功能的应用程序，上线部署。然后给个配置说明到运维，告诉他说如何需要灰度，要如何如何， 如果要限速，配置哪里哪里。这些工作，相信做微服务落地的公司，基本都跑不掉，需求是现实存在的，无非能否实现，以及实现多少的问题，但是毫无疑问的是，要做到这些，绝对不是一件容易的事情。
最后，当我们费力做到这些事情之后，运维跑来提了点要求，在他看来很合理的要求，比如说：简单点的加个黑名单，复杂点的要做个特殊的灰度：将来自iPhone的用户流量导1%到Stagging环境的2.0新版本……
这就提出一个严肃的问题，我们到底需要往业务程序里面塞多少管理和运维的功能? 就算hold的住技术和时间，我们有能力一个一个的满足各种运维和管理的需求吗？当你发现你开始疲于响应各种非功能性的需求时，就该开始反省了: 我们开发的是业务程序，它的核心价值在业务逻辑的处理和实现，将如此之多的时间精力花费在这些非业务功能上，这真的合理吗? 而且即使是在实现层面，微服务实施时，最重要的是如何划分微服务，如何制定接口协议，你该如何分配你有限的时间和资源？
Istio超越 spring cloud和dubbo 等传统开发框架之处，就在于不仅仅带来了远超这些框架所能提供的功能，而且也不需要应用程序为此做大量的改动，开发人员也不必为上面的功能实现进行大量的知识储备。
总之，Istio 大幅降低微服务架构下应用程序的开发难度，势必极大的推动微服务的普及。随着isito的成熟，微服务开发领域将迎来一次颠覆性的变革。