- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

华为云云原生钻石集训营第十五课：传统微服务框架接入Istio方案详解

菜鸟级攻城狮发表于 2021/08/18 22:01:03 2021/08/18

【摘要】华为云云原生钻石集训营第十五课：传统微服务框架接入Istio方案详解

课程目标：

学完本课程后，您将能够:

了解传统微服务SDK和网格服务治理的原理

了解传统微服务SDK遇到的问题和网格的解决方案

掌握传统微服务SDK，包括Spring Cloud和Dubbo等开发的服务接入网格的详细指导

1．微服务的概念和原理

2．传统微服务框架的问题和基于服务网格的解决方案

3．传统微服务框架在服务网格中集成的实践详细

从前序课程，我们了解了Istio服务网格的基础架构和用法。包括网格控制面架构、数据面架构和网格的流量和监控等内容。

在本节我们将专注网格实际使用中一个典型场景，那就是传统微服务框架开发的服务怎样在服务网格上部署和使用网格能力。

Istio 是一个由谷歌、IBM 与 Lyft 共同开发的开源项目，旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。Istio 项目能够为微服务架构提供流量管理机制，同时亦为其它增值功能（包括安全性、监控、路由、连接管理与策略等）创造了基础。这款软件利用久经考验的 Lyft Envoy 代理进行构建，可在无需对应用程序代码作出任何发动的前提下实现可视性与控制能力。Istio 项目是一款强大的工具，可帮助 CTO/CIO 们立足企业内部实施整体性安全、政策与合规性要求。

优势

集群规模可视性：在故障状况出现时，运营人员需要利用多种工具以始终关注集群运行状况并分析微服务状态图表。Istio 项目能够监控与应用程序及网络活动相关的数据，利用 Prometheus 与 Grafana 对这部分数据加以渲染，而后将相关指标与日志记录发送至任何收集、聚合与查询系统当中以实现功能扩展。Istio 项目亦利用 Zipkin 追踪分析性能热点并对分布式故障模式加以诊断。
弹性与效率：在开发微服务时，运营人员需要假设网络本身处于不可靠状态。运营人员能够利用重试、负载均衡、流量控制（HTTP/2）以及断路补偿等方式解决由网络可靠性低下所造成的各类常见故障模式。Istio 项目则提供一种统一方法以配置上述功能，使得运营人员能够更为轻松地运作高弹性水平服务网格。
开发人员生产力：Istio 项目能够确保开发人员专注于利用已选择的编程语言构建服务功能，从而极大提升其生产能力。另外，Istio 项目则负责以统一化方式处理弹性与网络挑战。开发人员无需将解决方案的分布式系统问题解决机制引入编写的代码当中。Istio 项目还能够支持 A/B 测试、金丝雀部署以及故障注入等常用功能，旨在进一步提高生产效率。
政策驱动型运营：Istio 项目能够授权具有不同职能的团队以实现独立运作。其将集群运营人员与功能开发人员进行周期性剥离，从而在无需更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够精确控制生产流量中各个子集的路由方式，从而匹配新的服务版本。另外，运营人员还能够在流量中注入故障或者提高延迟水平，用以测试服务见长的弹性 ; 同时设置速率限制以防止服务过载。Istio 项目还可用于强制执行合规性要求，例如在服务之间定义 CL 以确保仅具备授权的服务间可相互通信。
默认安全：分布式计算当中经常存在着大量网络安全问题。Istio 项目允许运营人员利用 TLS 连接以认证并保护各服务之间的所有通信，而不会给开发人员或者运营人员带来由证书管理造成的额外负担。其安全框架与新的 SPIFFE 规范保持一致，事实上谷歌公司一直在内部广泛使用类似的保障性系统。
增量化采用：在设计 Istio 项目时充分考虑到网络内所运行各服务的透明性，允许团队随着时间推移逐步采用 Istio 提供的各项功能。采用方可以先从启用集群范围内可视性起步，并在 Istio 在环境中的表现感到满意后根据实际需要启用其它功能。

熔断器基本上是一种软件设计模式，用于检测故障并封装防止故障进一步级联的逻辑。这有助于创建有弹性的微服务应用程序，以限制故障和延迟尖峰的影响。

2．传统微服务框架的问题和基于服务网格的解决方案

在微服务管理中常常需要使用到的一些列的组件：

服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、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 测试、金丝雀发布、限流、访问控制和端到端认证等。