一, 跨语言微服务框架 - Istio 简绍和概念

微服务的概念已经在各大公司实践开了，以Java为表明的spring boot成为了微服务的表明，K8S+Docker成为了微服务运行的最佳环境，微服务的概念已经离咱们没有那么遥远了。

固然微服务是复杂的，除了组件繁多还须要代码作出不少改造才能享受到它带来的优点，那么有没有一种方式能够不须要太多代码改动就可以在多种不一样的开发语言中灵活使用呢?

基于服务网格Istio就诞生了,拨云见日咱们今天就来一同窗习了解微服务和Istio相关的知识.

附上:

喵了个咪的博客:w-blog.cn

Istio官方地址:https://preliminary.istio.io/zh

Istio中文文档:https://preliminary.istio.io/zh/docs/

PS : 此处基于当前最新istio版本1.0.3版本进行搭建和演示，不一样的版本各类细节会有些许不一样！

一. 微服务

在开始讲解Istio以前咱们须要先了解微服务的概念，以及在微服务管理中经常须要使用到的一些列的组件：

• 服务注册：服务提供方将本身调用地址注册到服务注册中心，让服务调用方可以方便地找到本身。
• 服务发现：服务调用方从服务注册中心找到本身须要调用的服务的地址。
• 负载均衡：服务提供方通常以多实例的形式提供服务，负载均衡功能可以让服务调用方链接到合适的服务节点。而且，节点选择的工做对服务调用方来讲是透明的。
• 服务网关：服务网关是服务调用的惟一入口，能够在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
• 配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差异性，方便程序包的迁移。
• API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将全部微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户可以在统一的界面中使用系统。
• 分布式事务：对于重要的业务，须要经过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
• 调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展现出来。在系统出错时，能够方便地找到出错点。
• 支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就须要将大部分的工做自动化。如今，能够经过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以咱们两年的实践经验，能够这么说，若是没有合适的支撑平台或工具，就不要使用微服务架构。

微服务架构的优势：

• 下降系统复杂度：每一个服务都比较简单，只关注于一个业务功能。
• 松耦合：微服务架构方式是松耦合的，每一个微服务可由不一样团队独立开发，互不影响。
• 跨语言：只要符合服务 API 契约，开发人员能够自由选择开发技术。这就意味着开发人员能够采用新技术编写或重构服务，因为服务相对较小，因此这并不会对总体应用形成太大影响。
• 独立部署：微服务架构可使每一个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改能够在测试经过后当即部署。因此微服务架构也使得 CI／CD 成为可能。
• Docker 容器：和 Docker 容器结合的更好。
• DDD 领域驱动设计：和 DDD 的概念契合，结合开发会更好。

微服务架构的缺点：

• 微服务强调了服务大小，但实际上这并无一个统一的标准：业务逻辑应该按照什么规则划分为微服务，这自己就是一个经验工程。有些开发者主张 10-100 行代码就应该创建一个微服务。虽然创建小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
• 微服务的分布式特色带来的复杂性：开发人员须要基于 RPC 或者消息实现微服务之间的调用和通讯，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的至关棘手。
• 分区的数据库体系和分布式事务：更新多个业务实体的业务交易至关广泛，不一样服务可能拥有不一样的数据库。CAP 原理的约束，使得咱们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来讲是一个挑战。
• 测试挑战：传统的单体WEB应用只需测试单一的 REST API 便可，而对微服务进行测试，须要启动它依赖的全部其余服务。这种复杂性不可低估。
• 跨多个服务的更改：好比在传统单体应用中，如有 A、B、C 三个服务须要更改，A 依赖 B，B 依赖 C。咱们只需更改相应的模块，而后一次性部署便可。可是在微服务架构中，咱们须要仔细规划和协调每一个服务的变动部署。咱们须要先更新 C，而后更新 B，最后更新 A。
• 部署复杂：微服务由不一样的大量服务构成。每种服务可能拥有本身的配置、应用实例数量以及基础服务地址。这里就须要不一样的配置、部署、扩展和监控组件。此外，咱们还须要服务发现机制，以便服务能够发现与其通讯的其余服务的地址。所以，成功部署微服务应用须要开发人员有更好地部署策略和高度自动化的水平。

总的来讲（问题和挑战）：API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用以及测试。

二, 服务网格

第二点咱们须要了解的是服务网格，Istio 提供了一个完整的解决方案，经过为整个服务网格提供行为洞察和操做控制来知足微服务应用程序的多样化需求，Service Mesh这个术语一般用于描述构成这些应用程序的微服务网络以及应用之间的交互。

随着规模和复杂性的增加，服务网格愈来愈难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及一般更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

2017 年末，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。若是用一句话来解释什么是 Service Mesh，能够将它比做是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来讲通常无须关心 TCP/IP 这一层（好比经过 HTTP 协议的 RESTful 应用），一样使用 Service Mesh 也就无须关系服务之间的那些原来是经过应用程序或者其余框架实现的事情，好比 Spring Cloud、OSS，如今只要交给 Service Mesh 就能够了。

Service Mesh 的前因后果：

• 从最原始的主机之间直接使用网线相连
• 网络层的出现
• 集成到应用程序内部的控制流
• 分解到应用程序外部的控制流
• 应用程序的中集成服务发现和断路器
• 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候仍是集成在应用程序内部
• 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
• 最后做为微服务的中间层 Service Mesh 出现

Service Mesh 有以下几个特色：

• 应用程序间通信的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图：

关于微服务和服务网格的区别，个人一些理解：微服务更像是一个服务之间的生态，专一于服务治理等方面，而服务网格更专一于服务之间的通讯，以及和 DevOps 更好的结合。

三. Istio

最终万众期待的Istio诞生了，Istio于 2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，就在前不久2018年8月份1.0正式版本已经发布，简单一句概况就是Istio 容许您链接、保护、控制和观测服务。

链接

• 智能控制服务之间的流量和 API 调用，进行一系列测试，并经过红/黑部署逐步升级。

保护

• 经过托管身份验证、受权和服务之间通讯加密自动保护您的服务。

控制

• 应用策略并确保其执行使得资源在消费者之间公平分配。

观测

• 经过丰富的自动跟踪、监控和记录全部服务，了解正在发生的状况。

PS: 如下内容来自官网文档

Istio 服务网格逻辑上分为数据平面和控制平面。

数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理能够调节和控制微服务及 Mixer 之间全部的网络通讯。 控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。

下图显示了构成每一个面板的不一样组件：

Envoy

Istio 使用 Envoy 代理的扩展版本，Envoy 是以 C++ 开发的高性能代理，用于调解服务网格中全部服务的全部入站和出站流量。Envoy 的许多内置功能被 istio 发扬光大，例如：

• 动态服务发现
• 负载均衡
• TLS 终止
• HTTP/2 & gRPC 代理
• 熔断器
• 健康检查、基于百分比流量拆分的灰度发布
• 故障注入
• 丰富的度量指标

Envoy 被部署为 sidecar，和对应服务在同一个 Kubernetes pod 中。这容许 Istio 将大量关于流量行为的信号做为属性提取出来，而这些属性又能够在 Mixer 中用于执行策略决策，并发送给监控系统，以提供整个网格行为的信息。

Sidecar 代理模型还能够将 Istio 的功能添加到现有部署中，而无需从新构建或重写代码。能够阅读更多来了解为何咱们在设计目标中选择这种方式。

Mixer

Mixer 是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其余服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。有关属性提取和策略评估的更多信息，请参见 Mixer 配置。

Mixer 中包括一个灵活的插件模型，使其可以接入到各类主机环境和基础设施后端，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。

Pilot

Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 sidecar。

Pilot 将平台特定的服务发现机制抽象化并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 均可以使用的标准格式。这种松散耦合使得 Istio 可以在多种环境下运行（例如，Kubernetes、Consul、Nomad），同时保持用于流量管理的相同操做界面。

Citadel

Citadel 经过内置身份和凭证管理能够提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持基于角色的访问控制，以控制谁能够访问您的服务。

四. 服务监控链路监控

Istio结合了链路监控和服务监控,对于K8S状态监控也天然而然也在其中

zipkin + jaeger 来对zipkin的数据进行更加友好的展现

.

PS : 须要实现链路监控须要代码中作出基础的适配

prometheus + grafana 来对prometheus获取的数据进行展现监控报警配置