The sixth chapter nine analysis with you easily after blasting service mesh - istio life chapter

Series:


Index List: nine analyze with you easily complete explosion istio Service Grid Tutorial Series

table of Contents

1 Introduction

2 What is a Service Grid (service mesh)

3 What is istio

4 Why istio

5 istio core features

    5.1 traffic management

    5.2 secure

    5.3 policies

    5.4 observability

6 Multi-platform support


1 Introduction

        If you have any questions about the blog, please let me know.

1.png

        The last chapter introduces istio past life, tells the history of the evolution of the micro-service architecture model, also spoke micro service encountered problems and embarrassing dilemma facing today, where we'll go over.

        Currently micro-management service problems encountered:

Service governance is not uniform : different services will introduce different ways of governance of middleware, middleware and these technical standards and maintenance standards are different. Therefore, operation and maintenance personnel or infrastructure must master the use of each middleware, many times this is not the reality of limited human resources of a technology company.


Repeat-create the wheel : micro-services architecture that allows multi-language stack, multi-technology stack, but the common technical problems of different technology stack for communication, support services, service security, service monitoring, fuse / downgrade / current limiting, but requires its own solution program, it is a waste of costs.


Lack of standardized service management : Due to the lack of standardized service management, quality of service and therefore the micro-management of the whole technical staff rely on personal ability, experience and levels, which is something like a workshop era, thanks to high-quality artisan objects. But no standardization is clearly inconsistent with the trajectory of technological development.

        为了解决上面微服务治理中的痛点,大家普遍的诉求在于能不能有这么一个平台,既可以无侵入、透明、用户无感知的插入到现有的分布式微服务架构中,同时又可以解决一些通信所必须考虑的普遍问题(服务发现、负载均衡、超时重试、熔断/限流、监控、访问控制、认证授权等),将这些问题的解决方案统一下沉到平台层,而不再依靠引入第三方中间件(zookeeper、nginx、sentinal、hystrix、pinpoint/zipkin、spring security),并且所有的维护方式统一且标准化。

        于是服务网格出现了,istio 也出现了,而且一切出现得都是这么自然。

《圣经》旧约-创世纪篇:


原始太初,上帝创造了天地。地面一片空虚混沌,渊面黑暗,只有上帝的灵运行在水面上。上帝说:“要有光!”于是,就有了光。上帝把光和暗分开,把光称为白昼,把暗称为黑夜。夜晚过去后,清晨接着来临,这是第一天。


上帝说:“诸水之间要有穹苍,将水分为上下。”于是创造了穹苍,把水上下分开。他称穹苍为“天空”。夜晚过去,清晨接着来临,这是第二天。

......

        那么服务网格是什么?istio 又是什么呢?


2 何为服务网格(service mesh)

        下面看看 istio 是怎么描述服务网格的:

The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

        个人翻译如下:

服务网格是对微服务组成的一个可以互相通信的网络进行治理的规范。随着微服务的增长,服务网格也会变得越来越复杂和难以理解。服务网格治理的内容除了服务发现、负载均衡、失败恢复、指标收集、监控之外,还应该具有更复杂的运维要求,比如 A/B 测试、金丝雀发布、流量限制、访问控制和端到端认证。

3 何为 istio

        上面介绍了服务网格,下面再来介绍一下 istio,仍然引用 istio 官网的定义:

Cloud platforms provide a wealth of benefits for the organizations that use them. However, there’s no denying that adopting the cloud can put strains on DevOps teams. Developers must use microservices to architect for portability, meanwhile operators are managing extremely large hybrid and multi-cloud deployments. Istio lets you connect, secure, control, and observe services.


At a high level, Istio helps reduce the complexity of these deployments, and eases the strain on your development teams. It is a completely open source service mesh that layers transparently onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. Istio’s diverse feature set lets you successfully, and efficiently, run a distributed microservice architecture, and provides a uniform way to secure, connect, and monitor microservices.

        个人感觉介绍很啰嗦,建议你也别看了,我给你简单列举一下重点即可:

istio 是 service mesh 的具体解决方案。她就像一个尤物,不仅能满足服务网格规定的一切苛刻要求之外,还贴心地为你准备了一整套标准化、规格化的豪华级国际服务,等待着你的抽插。更难能可贵地是,拥有这么多优秀品质的她,竟然还是免费的!爽不爽!

4 为什么使用 istio

        下面是你选择 istio 的一些理由:

1 对 HTTP、gRPC、WebSocket 和 TCP 网络流量的自动负载均衡

2 通过丰富多样的路由规则、重试、故障转移和故障注入机制实现对流量行为进行细粒度控制

3 通过可插拔的策略层(联想成过滤器)和 API 实现对访问的控制、流量以及资源配额的限制

4 集群入口、集群内部、集群出口所有网络流量的全方位跟踪、记录和度量

5 保证服务之间通信的安全性

5 istio 核心特征

        istio 官方宣扬的特性是 traffic management(流控)、secure(安全)、polices(策略)、observability(可观察)。个人感觉这样的叙述太佶屈聱牙,一点都不口语化。

5.1 traffic management

        这个好理解,本质就是网络流量的管理。就像早晚高峰车辆限行,以及交警在发生交通事故疏导新路,这些都是在做流量的控制和路由。

        其实流量管理并不是服务网格化才出现的,早期的微服务时代就已经有流量控制了,比如负载均衡、熔断、限流、降级等,只不过早期这些功能的实现依赖中间件(比如 nginx、hystrix),如今服务网格时代,这些功能统一下沉到基础平台 istio 去实现了。

        istio 的流控主要是通过 Envoy 组件实现。有关技术细节,哥以后会专门告诉你。

5.2 secure

        说到 istio 的 secure 其实是有个范围的。这里的 secure 并不是没有边界,它主要是指微服务之间通信的 secure,即 pod 对 pod、service 对 service 层面通信的 secure。众所周知,istio 是 google、ibm 以及 lyft 公司 3p 后的产物。而 istio 的 secure 正是脱胎于 google 的 ALTS(应用层传输安全)这项技术,该项技术用于验证 google 服务之间的通信,保证传输中数据的安全,即应用层服务到服务通信的防护方式。这些功能早先在微服务时代对标就是 jwt、oauth2 等技术规范。

        The main function of istio secure there ACLS (access control), authentication (authentication, that is, to prove who you are), authorization (authorization, allowing you doing).

        istio secure function is achieved by Citadel this component. For technical details, after brother will specifically tell you.

5.3 policies

        istio policies duties are as follows:

Dynamic rate limiting the network service communication 1

2 restrict access to services, setting black and white list

Rewriting the network header 3 or redirect information

        Not only that, istio also allows you to add custom policy, policy through istio provided adapter integrated with istio.

        Be careful not to be confused with secure policies, policies are more human intervention control, and secure emphasis on safety.

        istio policies implemented function is achieved through mixer assembly. For technical details, after brother will specifically tell you.

5.4 observability

        observability characteristics refer to a variety of tools available to you to achieve all-round, three-dimensional cluster entrance, a cluster, the cluster traffic export monitoring, tracking and metrics. Monitoring the early days of micro-services approach is agent or middleware, for example: zabbix, pinpoint, zipkin and so on.

        istio observability function implemented by the mixer component implementation. Still the same, technical details, after brother will specifically tell you.

6 Multi-platform support

        istio can support multiple platforms, such as k8s, Consul, Mesos and a separate virtual machine.

        After brother will actually show you, the only thing you have to do is be patient and persistent screaming.

        Since then, nine analyze with you easily complete description of istio explosion. More exciting, so stay tuned.

Guess you like

Origin blog.51cto.com/14625168/2476019