istio入门(01)istio的优势在哪里?

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的成熟,微服务开发领域将迎来一次颠覆性的变革。

上一篇:spring mvc静态资源请求和


下一篇:cocoapods 安装中出的太多问题