1.what is CI、CD？

CI/CD或CICD通常指的是持续集成和持续交付或持续部署的组合实践。CI/CD通过在应用程序的构建、测试和部署中实施自动化，在开发和运营团队之间架起了桥梁。 现代DevOps实践涉及软件应用程序在整个开发生命周期内的持续开发、持续测试、持续集成、持续部署和持续监控。

DevOps

DevOps是一种重视“软件开发人员”和“IT运维技术人员”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 传统的软件组织将开发、IT运维和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法，是一个重要的课题

2.微服务与服务网格

微服务的优点

传统的单体应用比较适合于小项目，优点是：

  • 开发简单直接，集中式管理
  • 基本不会重复开发
  • 功能都在本地，没有分布式的管理开销和调用开销 当然它的缺点也十分明显，特别对于互联网公司来说：
  • 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
  • 代码维护难：代码功能耦合在一起，新人不知道何从下手
  • 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
  • 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
  • 扩展性不够：无法满足高并发情况下的业务需求

相较于整体式架构，微服务将应用程序拆分为更小层次的微服务，由不同的团队单独负责，降低内部的耦合程度，不同的微服务之间通过实现协定好的API进行通信。 这种架构具有灵活的可扩展性，部署轻松。

微服务的核心是服务治理，而服务治理的关键是服务划分。故微服务架构的本质就是对码农的分化和治理

参考链接 ： https://www.zhihu.com/question/65502802 https://xiaoxubeii.github.io/articles/microservices-architecture-introduction/

微服务的缺点

  • 微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手，定位故障点非常困难。
  • 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出的。
  • 分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单，因为单体应用往往只存在一个数据库。但在微服务架构下，不同服务可能拥有不同的数据库。CAP原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性
  • 服务数量非常多，部署、管理的工作量很大。
  • 开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
  • 测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

    为了降低软件故障带来的经济损失，

    ![[../images/Pasted image 20220918132710.png]]

微服务架构中组件繁多，各个组件所需要监控的指标不同。比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差。一般的做法是让各个组件提供报告自己当前状态的接口（metrics接口），这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。最后还需要一个UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警。

大部分组件都不需要自己动手开发，网络上有开源组件。小明下载了RedisExporter和MySQLExporter，这两个组件分别提供了Redis缓存和MySQL数据库的指标接口。微服务则根据各个服务的业务逻辑实现自定义的指标接口。然后小明采用Prometheus作为指标采集器，Grafana配置监控界面和邮件告警。这样一套微服务监控系统就搭建起来了： ![[../images/Pasted image 20220918132737.png]]
在微服务架构下，一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系。这个叫做链路跟踪。

要实现链路跟踪，每次服务调用会在HTTP的HEADERS中记录至少记录四项数据：

  • traceId：traceId标识一个用户请求的调用链路。具有相同traceId的调用属于同一条链路。
  • spanId：标识一次服务调用的ID，即链路跟踪的节点ID。
  • parentId：父节点的spanId。
  • requestTime & responseTime：请求时间和响应时间。

另外，还需要调用日志收集与存储的组件，以及展示链路调用的UI组件。了解了理论基础后，小明选用了Dapper的一个开源实现Zipkin。然后手指一抖，写了个HTTP请求的拦截器，在每次HTTP请求时生成这些数据注入到HEADERS，同时异步发送调用日志到Zipkin的日志收集器中。这里额外提一下，HTTP请求的拦截器，可以在微服务的代码中实现，也可以使用一个网络代理组件来实现（不过这样子每个微服务都需要加一层代理）。

链路跟踪只能定位到哪个服务出现问题，不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。

![[../images/Pasted image 20220918133104.png]]

日志分析组件应该在微服务兴起之前就被广泛使用了。即使单体应用架构，当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。

因此，在应用规模变大时，我们需要一个日志的“搜索引擎”。以便于能准确的找到想要的日志。另外，数据源一侧还需要收集日志的组件和展示结果的UI组件：

小明调查了一下，使用了大名鼎鼎地ELK日志分析组件。ELK是Elasticsearch、Logstash和Kibana三个组件的缩写。

  • Elasticsearch：搜索引擎，同时也是日志的存储。
  • Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch。
  • Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户。

最后还有一个小问题是如何将日志发送到Logstash。一种方案是在日志输出的时候直接调用Logstash接口将日志发送过去。这样一来又（咦，为啥要用“又”）要修改代码……于是小明选用了另一种方案：日志仍然输出到文件，每个服务里再部署个Agent扫描日志文件然后输出给Logstash。

网关

拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……

为了应对这些情况，微服务的调用需要一个把关的东西，也就是网关。在调用者和被调用者中间加一层网关，每次调用时进行权限校验。另外，网关也可以作为一个提供服务接口文档的平台。

使用网关有一个问题就是要决定在多大粒度上使用：最粗粒度的方案是整个微服务一个网关，微服务外部通过网关访问微服务，微服务内部则直接调用；最细粒度则是所有调用，不管是微服务内部调用或者来自外部的调用，都必须通过网关。折中的方案是按照业务领域将微服务分成几个区，区内直接调用，区间通过网关调用。

服务注册与发现 - 动态扩容

前面的组件，都是旨在降低故障发生的可能性。然而故障总是会发生的，所以另一个需要研究的是如何降低故障产生的影响。

最粗暴的（也是最常用的）故障处理策略就是冗余。一般来说，一个服务都会部署多个实例，这样一来能够分担压力提高性能，二来即使一个实例挂了其他实例还能响应。

冗余的一个问题是使用几个冗余？这个问题在时间轴上并没有一个切确的答案。根据服务功能、时间段的不同，需要不同数量的实例。比如在平日里，可能4个实例已经够用；而在促销活动时，流量大增，可能需要40个实例。因此冗余数量并不是一个固定的值，而是根据需要实时调整的。

一般来说新增实例的操作为：

  1. 部署新实例
  2. 将新实例注册到负载均衡或DNS上

操作只有两步，但如果注册到负载均衡或DNS的操作为人工操作的话，那事情就不简单了。想想新增40个实例后，要手工输入40个IP的感觉……

解决这个问题的方案是服务自动注册与发现。首先，需要部署一个服务发现服务，它提供所有已注册服务的地址信息的服务。DNS也算是一种服务发现服务。然后各个应用服务在启动时自动将自己注册到服务发现服务上。并且应用服务启动后会实时（定期）从服务发现服务同步各个应用服务的地址列表到本地。服务发现服务也会定期检查应用服务的健康状态，去掉不健康的实例地址。这样新增实例时只需要部署新实例，实例下线时直接关停服务即可，服务发现会自动检查服务实例的增减。

服务发现还会跟客户端负载均衡配合使用。由于应用服务已经同步服务地址列表在本地了，所以访问微服务时，可以自己决定负载策略。甚至可以在服务注册时加入一些元数据（服务版本等信息），客户端负载则根据这些元数据进行流量控制，实现A/B测试、蓝绿发布等功能。

服务发现有很多组件可以选择，比如说Zookeeper 、Eureka、Consul、Etcd等

熔断

当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。 ![[../images/Pasted image 20220918134546.png]]

服务降级

当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。

限流

一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。

容器是微服务架构的绝佳示例，因为它们可让您专注于开发服务，而无需担心依赖项。现代云原生应用通常使用容器构建为微服务。

测试

微服务架构下，测试分为三个层次：

  1. 端到端测试：覆盖整个系统，一般在用户界面机型测试。
  2. 服务测试：针对服务接口进行测试。
  3. 单元测试：针对代码单元进行测试。

三种测试从上到下实施的容易程度递增，但是测试效果递减。端到端测试最费时费力，但是通过测试后我们对系统最有信心。单元测试最容易实施，效率也最高，但是测试后不能保证整个系统没有问题。

由于端到端测试实施难度较大，一般只对核心功能做端到端测试。一旦端到端测试失败，则需要将其分解到单元测试：则分析失败原因，然后编写单元测试来重现这个问题，这样未来我们便可以更快地捕获同样的错误。

服务测试的难度在于服务会经常依赖一些其他服务。这个问题可以通过Mock Server解决：

![[../images/Pasted image 20220918134840.png]] 单元测试大家都很熟悉了。我们一般会编写大量的单元测试（包括回归测试）尽量覆盖所有代码。

微服务框架

指标接口、链路跟踪注入、日志引流、服务注册发现、路由规则等组件以及熔断、限流等功能都需要在应用服务上添加一些对接代码。如果让每个应用服务自己实现是非常耗时耗力的。基于DRY的原则，小明开发了一套微服务框架，将与各个组件对接的代码和另外一些公共代码抽离到框架中，所有的应用服务都统一使用这套框架进行开发。

使用微服务框架可以实现很多自定义的功能。甚至可以将程序调用堆栈信息注入到链路跟踪，实现代码级别的链路跟踪。或者输出线程池、连接池的状态信息，实时监控服务底层状态。

使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。

SpingCloud

Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等）

Dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分包含：

  • 远程通讯： 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
  • 集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
  • 自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

4.jpg

但是显而易见，无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境，它们的设计目的并不是为了支持通用性和多语言性。并且它们只是Dev层的框架，缺少DevOps的整体解决方案（这正是微服务架构需要关注的）。而随之而来的便是Service Mesh的兴起。

另一条路 - Service Mesh

另一种抽象公共代码的方法是直接将这些代码抽象到一个反向代理组件。每个服务都额外部署这个代理组件，所有出站入站的流量都通过该组件进行处理和转发。这个组件被称为Sidecar。

Sidecar不会产生额外网络成本。Sidecar会和微服务节点部署在同一台主机上并且共用相同的虚拟网卡。所以sidecar和微服务节点的通信实际上都只是通过内存拷贝实现的。

图片来自：Pattern: Service Mesh

Sidecar只负责网络通信。还需要有个组件来统一管理所有sidecar的配置。在Service Mesh中，负责网络通信的部分叫数据平面（data plane），负责配置管理的部分叫控制平面（control plane）。数据平面和控制平面构成了Service Mesh的基本架构。

图片来自：Pattern: Service Mesh

Sevice Mesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便。它经常被诟病的则是性能问题。即使回环网络不会产生实际的网络请求，但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能。 Service Mesh有如下几个特点：

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

    Linkerd

    Linkerd是开源网络代理，设计为以服务网格部署：用于管理，控制和监控应用程序内的服务与服务间通讯的专用层。

Linkerd旨在解决Twitter、Yahoo、Google和Microsoft等公司运营大型生产系统时发现的问题。根据经验，最复杂，令人惊奇和紧急行为的来源通常不是服务本身，而是服务之间的通讯。Linkerd解决了这些问题，不仅仅是控制通讯机制，而是在其上提供一个抽象层。

![[../images/Pasted image 20220918141210.png]]

Istio

Istio是一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络，具备负载均衡、服务间认证、监控等功能，而不需要改动任何服务代码。想要为服务增加对Istio的支持，您只需要在环境中部署一个特殊的边车（sidecar），使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。

Istio目前仅支持在Kubernetes上的服务部署，但未来版本中将支持其他环境。

Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能：

  • 流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
  • 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
  • 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
  • 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

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

  • 数据面板由一组智能代理（Envoy）组成，代理部署为边车，调解和控制微服务之间所有的网络通信。
  • 控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。

下图显示了构成每个面板的不同组件：
![[../images/Pasted image 20220918141422.png]]

Conduit

Conduit是为Kubernetes设计的一个超轻型服务网格服务，它可透明地管理在Kubernetes上运行的服务的运行时通信，使得它们更安全可靠。Conduit提供了可见性、可靠性和安全性的功能，而无需更改代码。

Conduit service mesh也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板，并对外提供北向接口。

对比

Linkerd和Envoy比较相似，都是一种面向服务通信的网络代理，均可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通信问题，使得应用对服务通信无感知，这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar，多个类似Linkerd和Envoy的proxy互相连接，就组成了service mesh。

而Istio则是站在了一个更高的角度，它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的所有网络通信，而Control Plane负责管理Data Plane Proxy：
![[../images/Pasted image 20220918141546.png]]

并且Istio天生的支持Kubernetes，这也弥合了应用调度框架与Service Mesh之间的空隙。

关于Conduit的资料较少，从官方介绍看它的定位和功能与Istio类似。

3. 云原生网关

曾经关炙手可热的 Zuul/SpringCloud Gateway/Kong 等在其网关位置上开始显得力不从心。它们欠缺发现容器服务的能力，性能可能不如 Nginx Ingress，可观测、安全等方面都需要二次开发再集。云原生网关从开始就一直在强调，将流量网关（Kubernetes Ingress、Nginx）和微服务网关（Spring Cloud Gateway、Zuul 网关等）二合一，降低 50%资源成本，同时缩短了请求时间，降低运维复杂度。

仅仅只是二合一显然不够满足我们的期望，看看它还有什么：

  1. 开箱即用，  默认支持全局看板、实例监控、日志检索、业务 TOP 榜、日志投递、链路追踪及报警管理等体系化可观测能力，让你轻松了解微服务及 API 质量情况。
  2. 卓越的性能，详见下文性能更强劲。
  3. 支持 Ingress 标准，Kubernetes 体系首选网关产品。
  4. 多种服务发现，支持 ACK 容器服务、Nacos 等多种服务发现方式，可以同时接入多个 Kubernetes 集群。
  5. 基于 envoy+istio 实现，完美兼容服务网格，技术大势所趋。 https://jimmysong.io/kubernetes-handbook/usecases/service-mesh-vs-api-gateway.html

    4.Istio