HCIP学习笔记-云原生应用架构-8

1.云原生应用与微服务介绍

1.1 架构演进

• 架构的演进和选择，企业要在快速发展业务和一个“优美”的应用架构之间进行取舍，微服务化是未来趋势，特点包括:容错性、快速上线能力、功能复杂度增加、高可用性、需求响应能力、可管理性、模块独立发布等。
• 单体架构的特点:所有功能都集中在一个项目中。单体架构简单，前期开发成本低，周期短，小型项目首选。但是全部功能集中在一个项目中，随着项目的变大，变的不易开发，扩展，维护。
• 单体架构的特点:以单体架构规模的项目为单位进行垂直划分项目，项目架构简单，前期开发成本低，周期短，小型项目的首选。通过垂直拆分，原来的单体项目不至于无限扩大。
• SOA(Service-Oriented Architecture)的特点: 基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。各个项目(系统)与服务之间采用Webservice、RPC等方式进行通信。能提高开发效率，提高系统的可重用性、可维护性。可以针对不同服务的特点制定集群及优化方案。
• SOA架构的缺点:系统与服务的界限模糊，不利于开发及维护。抽取的服务的粒度过大，系统与服务之间耦合性高。
• 微服务架构的特点:微服务架构风格的开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API轻量的机制来相互通信。服务拆分粒度更细，有利于资源重复利用，提高开发效率。可以更加精准地制定每个服务的优化方案，提高系统可维护性。适用于互联网时代，产品迭代周期更短。

1.2 单体架构

• 复杂性高:由于是“人单体的系统，所以整个系统的模块是耦合在一起的，模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。
• 服务性能问题:单体系统遇到性能瓶颈问题，只能横向扩展，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。
• 扩缩容能力受限:单体应用只能作为一个整体进行扩展，影响范围大，无法根据业务模块的需要进行单个模块的伸缩。
• 无法做故障隔离: 当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题(如某个请求堵塞 )，那么都有可能会造成整个系统的崩溃发布的影响范围较大，8每次发布都是整个系统进行发布，发布会导致整个系统的重启对于大型的综合系统挑战比较大，如果将各个模块拆分，哪个部分做了修改，只发布哪个部分所在的模块即可。
• 部署速度逐渐变慢，随着代码的增加，构建和部署的时间也会增加。
• 阻碍技术创新、单体应用，往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。
• 单体架构顾名思义就是一个归档包，如rar包或者iar包，包含了所有功能的应用程序这是一种比较传统的架构风格。在软件开发的早期，因为单体架构部署简单，技术单、用人成本低等特点，大家基本都采用这一架构模式。但是随着互联网时代的到来随着业务需求复杂度的提高以及交付频率的不断加快，传统的单体架构，因为下面这些缺陷越来越难以满足开发人员的要求。

1.3 SOA架构

• SOA结构将应用解 ，使其模块化，将各功能构建成独立单元提供服务
• 可以理解为在SOA架构中包含多个服务，服务之间通过相互依赖或者通过通信机制来完成相互通信的，最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用 。
• SOA主要解决以下问题
  • 系统集成:站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如ESB、以及技术规范、服务管理规范;
  • 系统的服务化:站在功能的角度，把业务逻辑抽象成可复用、可组装的服务通过服务的编排实现业务的快速再生。目的:把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用;
  • 业务的服务化:站在企业的角度，把企业职能抽象成可复用、可组装的服务;把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力;前面两步都是从技术层面来解决系统调用、系统功能复用的问题。

1.4 ESB企业服务总线

• 总线一词是对在一台电脑的不同设备间运输比特的物理总线的引申。ESB在更高抽象层次上提供类似的功能。在一个使用ESB的企业架构中，应用将通过总线交互，而总线扮演着应用间的信息调度的角色。这种方法的主要优点是它减少了应用间交互所需的点对点连接的数量。这样，另一方面使得对主要软件变化带来的影响进行分析更简单更直观了。通过减少一个应用系统的连接点数量，对这个系统中的一个组件的改造过程变得简单了。
• 企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。
• 未来企业的集成架构演进将会突破企业集成边界，实现集成应用API、消息、设备数据、跨云等多个场景的集成，为企业的一切应用、大数据9云服务、设备及合作伙伴构建连接。传统的由IT团队控制的“集成工厂”模式将转变为支持由业务线，子公司，应用程序开发团队和最终业务用户负责的自助集成模式，也就是我们所说的“统混合集成平台”。

1.5 微服务介绍

• 微服务的起源是由Peter Rodgers博士于2005年度云端运算博览会提出的微Web服务(Micro-Web-Service )开始，Juval Lowy则是与他有类似的想法，将类别变成细粒服务(Granular Services )y其核心想法是让服务是由类似Unix管道的存取方式使用2014年Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程式构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通讯。同时服务会使用最小的规模的集中管理(例如Docker )能力，服务可以用不同的程式语言与资料库等元件实作。
• 微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。
• 微服务架构的出现是因为单体架构· Monolithic)在其内部一个小改动，都会影响其他模块。特别是在云上发布，任何一个小的改动，都需要统一编译和发布。对某个模块进扩展，也需要整体扩展。所以出现通过一系列的微服务来构建应用，各个微服务之间可以独立部署、独立扩展以及提供模块化的边界，还可以使用不同的语言进行开发。

1.6 微服务架构

• 微服务英文名称Microservice，Microservice架构模式就是将整个Web应用组织为-系列小的Web服务。这些小的Web服务可以独立地编译及部署，并通过各自暴露的API接口相互通讯。它们彼此相互协作，作为一个整体为用户提供功能，却可以独立地进行扩展。
• 微服务( Microservices )是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块(Small Building Blocks)为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集相互通信。
• 微服务运用了以业务功能的设计概念，应用程序在设计时就能先以业务功能或流程设计先行分割，将各个业务功能都独立实现成一个能自主执行的个体服务，然后再利用相同的协议将所有应用程序需要的服务都组合起来，形成一个应用程序。若需要针对特定业务功能进行扩展时0只要对该业务功能的服务进行扩展就好，不需要整个应用程序都扩展，同时，由于微服务是以业务功能导向的实现，因此不会受到应用程序的干扰，微服务的管理员可以视运算资源的需要来配置微服务到不同的运算资源内，或是布建新的运算资源并将它配置进去
• API网关一般位于每个API请求的执行路径上，它属于数据平面心接收来自客户端的请求，将请求反向代理到底层API。并在此之前执行流量控制和用户策略。
• 在将请求代理回原始客户端之前，它还可以响应底层API的指令，再次执行相应的策略RESTful API是REST风格的API，RESTFUL是一种网络应用程序的设计风格和开发方式可以使用XML格式定义或JSON格式定义。

1.7 微服务的特点

• 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下应用被分解为多个可管理的分支或服务，每个服务间通过API进行定义。
• 微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
• 由于微服务是独立实现和部署的，即在独立的进程内运行，因此可以独立监控和扩展
• 微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。
• 微服务架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。

2.云原生应用的主流狂街

2.1 架构发展的演变简介

• 早期让两台或多台计算机相互通信时，通信是需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理丢包、乱序、重试等一系列问题，因此服务除了处理业务逻辑外，还需要对网络传输等问题进行处理。
• 上世纪八十年代，随着TCP协议出现了，解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。
• 上世纪九十年代，在TCP出现后，机器之间的网络通信不再是下个难题，以GFS/BigTable/MapReduce为代表的分布式系统得以蓬勃发展。这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、Quota限制、监控等等，于是服务根据业务需求来实现一部分所需的通信语义。
• 为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，一些面向微服务架构的开发框架开始出现，如Twitter的Finagle、Facebook的Proxygen以及SpringCloud等，这些框架实现了分布式系统通信需要的各种通用语义功能。
• 虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，追踪和解决框架出现的问题也绝非易事;且开发框架通常只支持一种或几种特定的语言，导致没有框架支持的语言编写的服务，很难融入面向微服务的架构体系;复杂项目依赖导致版本兼容问题非常棘手，框架库的升级也无法对服务透明。因此以Linkerd、Envoy为代表的代理模式(边车模式)应运而生，这就是第一代Service Mesh。
• 第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。在这种模型中，每个服务都将有一个伴随代理sideCar，服务之间仅通过SideCar代理进行通信。这就是以istio为代表的第二代Service Mesh ( 由Google、IBM、Lyft等公司推出Istio )。

2.2 Spring Cloud简介

• Spring Cloud被称为构建分布式微服务系统的“全家桶”，它并不是某一门技术，而是一系列微服务解决方案或框架的有序集合。它将市面上成熟的、经过验证的微服务框架整合起来，并通过Spring Boot进行再封装，屏蔽掉其中复杂的配置和实现原理为开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。
• Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架“Spring Boot化的封装和抽象，也是数量最多的项目;第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka/ActiveMQ这样的角色。
• Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot致力于在蓬勃发展的快速应用开发领域( rapid application development)成为领导者。
• Spring Cloud的特点:
  • 有强大的Spring社区、Netflix等公司支持，并且开源社区贡献非常活跃,标准化的将微服务的成熟产品和框架结合一起，Spring Cloud提供整套的微服务解决方案，开发成本较低，且风险较小
  • 基于Spring Boot，具有简单配置、快速开发、轻松部署、方便测试的特点
  • 支持REST服务调用，相比于RPC，更加轻量化和灵活(服务之间只依赖一纸契约，不存在代码级别的强依赖 )，有利于跨语言服务的实现，以及服务的发布部署。
  • 提供了Docker及Kubernetes微服务编排支持

2.3 Service Mesh特点

• Service Mesh (中文译做服务网格)这一概念由Buoyant公司首先提出。2016年第次公开使用，2017年该公司发布了第一个Service Mesh产品Linkerd，这篇同一时间发表的文章What’s a service mesh? And why do I need one? 也被业界公认是Service Mesh的权威定义。
• 在没有服务网格层的时候，逻辑管理的通信可以编码到每个服务中，但随着通信变得越来越复杂，微服务之间通信越来越复杂，逻辑管理的通信也变得复杂，这是时候，，通过服务网格，可以将大量离散服务整合服务网格就专门处理复杂的服务通信问题，为一个功能应用。
• 如果用一句话来解释什么是Service Mesh，可以将它比作是应用程序或微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。开发应用程序来说一般无须关心TCP/IP这一层，同样使用Service Mesh也无须关心服务之间原本通过服务框架实现的事情，比如Spring Cloud、Netflix Oss和其他中间件，只要交给Service Mesh即可。
• 如果没有服务网格，每项微服务都需要进行逻辑编码，才能管理服务间通信，无法专注业务开发，并且通信故障难以诊断，因为管理服务间通信的逻辑隐藏在每项服务中
• 服务网格(Service Mesh)通常用于描述构成应用程序的微服务网络以及应用之间的交互。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如蓝绿发布、金丝雀发布、限流、访问控制和端到端认证等。

2.4 Service Mesh架构

• 每个应用微服务之间的通信都需要指定好规则来说明如何从服务A点到达B点，这些规则就在各个服务的逻辑管理层定义，服务网格就会在每个服务中提取逻辑管理的服务间通信规则，并将其抽象为一个基础架构层，并且服务网格不会在各个微服务运行时环境中添加新功能。当各个微服务进行通信的时候，请求将通过服务网格的代理在微服务之间路由，构成服务网站的各个代理也称为SideCar，因为SideCar与每个服务并行运行，与每项服务分离，独立运行，这些sideCar代理就构成了网格式网络。SideCar代理与微服务并肩协作，用于将请求路由给其他代理。
• SideCar是一种将应用功能从应用本身剥离出来作为单独进程的设计模式，可以允许向应用中无侵入的添加功能，避免为了满足第三方需求而添加额外的代码。在软件架构中，SideCar附加到主应用，或者叫父应用上，以扩展、增强功能特性，同时SideCar与主应用是松耦合的。
• 在服务网格中，服务实例及其SideCar代理被称为构成数据平面，其中不仅包括数据管理，还包括请求处理和响应。服务网格还包括一个用于管理服务之间交互的控制平面，这些交互由它们的SideCar代理协调。
• 服务网格的工作流程: 控制平面将整个网格中的服务配置推送到所有节点的SideCar代理中。路由信息可以动态配置，可以是全局配置也可以为某些服务单独配置。当SideCar 确认了目的地址后w将流量发送到相应服务发现端点下在Kubernetes中是service，然后service会将服务转发给后端的实例。SideCar根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。SideCar将请求发送给该实例，同时记录响应类型和延迟数据。如果该实例挂了或者进程不工作了，SideCar将把请求发送到其他实例上重试。如果该实例持续返回error，SideCar会将该实例从负载均衡池中移除，稍后再周期性得重试。如果请求的截止时间已过，SideCar主动失败该请求，而不是再次尝试添加负载。SideCar以metrrc和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中metric系统

2.5 ServiceComb

• ServiceComb项目源于华为微服务引擎(CSE )。CSE借鉴和继承了这些框架的优点并着重从如下方面解决微服务面临的问题:
  • 微服务通信性能
  • 微服务运维和治理。性能监控、流量控制、隔离容错、灰度发布等。
  • 遗留系统改造
  • 配套DevOps，以开发框架为中心，完善全生命周期的DevOps工具集。包括服0务接口兼容性管理、契约测试、开发流水线、统一运维等。
• ServiceComb由华为公司于2017年11月捐赠给Apache并启动孵化，之后在Apache导师的指导下由孵化器管理委员会成员进行经营孵化，这也是业界首个微服务项目在Apache孵化并毕业成为顶级项目。

2.6 Istio介绍

• lstio是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用程序里它也是一个平台，拥有可以集成任何日志、遥测和策略系统的API接口。Istio多样化的特性使用户能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。
• 早期SideCar模式的ServiceMesh，将通信和通信链路治理的所有功能都放到代理服务中，并且由于承载了太多的特性和功能，会使得数据平面代理的更新和修改会特别频繁，影响代理服务的稳定性。同时Service Mesh模式下，数据平面代理承载了微服务通信的全部流量，对稳定性要求极高。为了解决上述问题，将策略和配置决策逻辑从代理服务中脱离出来，形成了独立的控制平面，这就是第二代Service Mesh。
• lstio由两个部分组成: 控制平面和数据平面
  • 数据平面是业务之间的通信平面。如果没有一个服务网格，网络就无法理解正在发送的流量，也无法根据它是哪种类型的流量，或者它从谁那里来，到谁那里去做出任何决定。
  • 控制平面获取所需的配置和服务视图，并动态地对代理服务器进行编程，随着规则或环境的变化更新它们。

3.华为云原生应用的解决方案

3.1 应用服务网络ASM

• 覆盖全应用形态，支持容器、传统微服务、第三方服务等多种应用平滑接入、统一治理。支持多云、混合云复杂场景多种网络条件下服务跨集群流量混合管理，大规模网格，提供智能运维、智能扩缩容，帮助用户自动透明的管理应用访问
• 高性能、低损耗、轻量、多形态网格数据面，支持每Pod、每Node2卸载形态，加快SideCar转发效率。灵活拓扑学习进行配置优化，优化网格控制面资源。
• 华为云ASM能够很好的解决云原生应用的管理、网络连接，以及安全管理等应用网络治理等问题。
• 华为云ASM产品与CCE云容器引擎深度整合，提供非侵人。智能流量治理的应用全生命周期管理方案，增强了华为云容器服务全栈能力，并在易用性、可靠性、可视化等方面进行一系列增强，为客户提供开箱即用的上手体验。

3.1.1 ASM解决的主要问题

3.1.2 ASM服务产品架构

• 混合部署:后续支持虚拟机应用和容器应用混合部署的统一治理
• 可观察性: 华为专业云服务开箱即用，提供端到端智能全局的监控、日志、拓扑、调用链。
• 多云混合云场景全局统一服务治理，支持多种基础设施(多容器集群/容器一虚机/虚机一物理机)的统一服务治理，跨集群的灰度、拓扑、调用链。
• 协议扩展: 提供和SpringCloud微服务SDK的结合方案。
• 社区和开源: lstio社区贡献全球排名第三，快速解决社区版本问题和需求。大客户需求快速落版本，并提及社区主干，和社区兼容。

3.1.3 基于ASM的灰度发布

• 支持的灰度发布策略:
  • 基于请求内容灰度规则:支持基于请求内容灰度规则，可以配置Header、Cookie等多种请求信息。
  • 基于流量比例灰度规则:s支持基于流量比例灰度规则，根据权重比例分配流量
  • 金丝雀灰度流程: 提供向导方式引导用户完成金丝雀灰度流程，包括灰度版本上线、观察灰度版本运行、配置灰度规则、观测访问情况、切分流量等。
  • 蓝绿灰度流程: 提供向导方式引导用户完成蓝绿灰度流程，包括灰度版本上线观察灰度版本运行观测访问情况、版本切换等。

3.1.4 设施发现及多集群管理

• 提供免运维的托管控制面，提供多云多集群的全局统一的服务治理、灰度、安全和服务运行监控能力，并支持容器和VM等多种基础设施的统一服务发现和管理。
• 多个集群的网格共享?“套根证书，给数据面的服务实例分发密钥和证书对，并定期替换密钥证书，根据需要撤销密钥证书。在服务间访问时，网格的数据面代理就会代理本地服务和对端进行双向认证、通道加密。这里的双向认证的服务双方可以来自两个不同的集群，从而做到跨集群的透明的端到端双向认证。
• 支持基于应用拓扑对服务配置负载均衡、服务路由、故障注入、熔断容错等治理规则并结合一站式治理系统，提供实时的、可视化的微服务流量管理;无侵入智能流量治理，应用无需任何改造，即可进行动态的智能路由和弹性流量管理
  • 权重、内容、TCP/IP等路由规则，实现应用灵活灰度发布
  • HTTP会话保持，满足业务处理持续性诉求
  • 限流、熔断，实现服务间链路稳定、可靠。
  • 网络长连接管理降低资源损耗，提升网络吞吐量
  • 服务安全认证: 认证、鉴权、审计等，提供服务安全保障基石

3.1.5 统一的控制治理策略，实时流量监控

• 支持基于应用拓扑对服务配置负载均衡、服务路由、故障注入、熔断容错等治理规则，并结合一站式治理系统，提供实时的、可视化的微服务流量管理，无侵入智能流量治理，应用无需任何改造，即可进行动态的智能路由和弹性流量管理。
  • 权重、内容、TCP/IP等路由规则，实现应用灵活灰度发布。
  • HTTP会话保持，满足业务处理持续性诉求
  • 限流、熔断，实现服务间链路稳定、可靠。
  • 网络长连接管理降低资源损耗，提升网络吞吐量
  • 服务安全认证:认证、鉴权、审计等，提供服务安全保障基石
• 支持基于请求内容/浏览器/OS分发
• 支持基于流量比例分发

3.1.6 流量治理

• 应用服务网格ASM当前支持重试、超时、连接池、熔断、负载均衡、HTTP头域、故障注入等流量治理能力，可满足大多数业务场景的治理需求。
• 流量治理:
  • 支持权重、内容、TCP/IP等路由规则，实现应用灵活灰度发布
  • 支持HTTP会话保持，满足业务处理持续性诉求
  • 支持限流、熔断，实现服务间链路稳定、可靠。
  • 支持网络长连接管理降低资源损耗，提升网络吞吐量
  • 支持服务安全认证: 认证、鉴权、审计等，提供服务安全保障基石

3.1.7 适用场景

• 运营容器化的基础设施带来了一系列新的挑战。我们需要增强容器、评估API端点的性能以及识别出基础设施中的有害部分。lstio服务网格可在不修改代码的情况下实现API增强，并且不会带来服务延迟。
• 通常产品优化迭代的方式，是直接将某版本上线发布给全部用户，一旦遇到线上事故(或BUG)，对用户的影响极大，解决问题周期较长，甚至有时不得不回滚到前一版本，严重影响了用户体验。灰度发布是版本升级平滑过渡的一种方式，当版本升级时使部分用户使用高版本，其他用户继续使用低版本，待高版本稳定后，逐步扩大范围把所有用户流量都迁移到高版本上面来。

3.2 应用中间件介绍

3.2.1 分布式消息服务

• 主要特性:
  • 简单易用:即开即用，可视化操作，按需自助创建，自动化部署，分钟级创建实例，立即使用，实时查看和管理消息实例。
  • 稳定可靠，无忧运维:支持跨AZ部署，解决了开源的可用性问题 ( Kafka脑裂多controller等)，故障自动发现告警和切换，保证用户关键业务的可靠运行
  • 实践验证: 华为VMALL 双11等大规模考验，广泛部署运行在全球客户云业务系统里，并紧随社区主流，服务得到客户对云的充分信任。

3.2.1.1 分布式消息服务 Kafka

• Zookeeper: 分布式的协调应用，存储Kafka元数据
• 客户端:
  • 生产者( Producen2o2向主题发布消息的客户端应用程序，可持续向多个主题发送消息。
  • 消费者( Consumer ): 订阅这些主题的客户端，可同时订阅多个主题
• 服务端:由被称为Broker的服务进程构成，一个kafka集群由多个broker组成。
• Kafka:分布式的消息流处理中间件
• Broker:负责接收和处理客户端发送过来的请求，以及对消息进行持久化
• Topic;Kafka中发布订阅的对象，每个业务、每个应用甚至每类数据都可以创建专属的主题，
• Topic按分区存储。
• kafka高可用机制:
  • broker运行在不同的机器上，当一台出现故障时，其他broker依然可以对外提供服务。
  • 备份机制 (Replication），把相同的数据拷贝到多台机器个作为副本。

3.2.1.2 分布式消息服务RabbitMQ

• 即开即用: 分布式消息服务RabbitMQ版提供单机和集群的消息实例，拥有丰富内存规格，可以通过控制台直接下单购买并创建，无需单独准备服务器资源。
• 消息特性丰富:支持AMOP协议，支持普通消息、广播消息、死信、延迟消息等特性
• 灵活路由: 在RabbitMQ中，生产者将消息发送到交换器，由交换器将消息路由到队列中。交换器支持direct，topic，headers和fanout四种路由方式;同时支持交换机组合和自定义。
• 高可用: RabbitMQ集群提供镜像队列，可通过镜像在其他节点同步数据，单节点宕机时，仍可通过唯一的访问地址对外提供服务，数据不丢失。
• 监控和告警:支持对RabbitMQ实例状态进行监控，支持对集群每个代理的内存.CPU、网络流量等进行监控。如果集群或节点状态异常，将触发告警。
• AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不司的开发语言等条件的限制。

3.2.1.3 分布式消息服务RocketMQ

• 支持的消息类型
  • 普通消息:没有特殊功能的消息，区别于延迟消息、顺序消息和事务消息1
  • 延迟消息/定时消息: 生产者生产消息到RocketMO版后，消息不会立即被消费而是延迟到特定时间后才会发送给消费者进行消费。
  • 顺序消息:消费者按照消息发送的顺序来消费消息
  • 事务消息: 提供类似X/Open XA的分布事务功能，通过事务消息能达到分布式事务的最终一致。
• Producer:消息生产者，就是投递消息的程序。
• Consumer:消息消费者，就是接受消息的程序
• Namesrv: 保存topic路由信息，客户端生产、消费需要先访问namesrv获取topic路由信息。
• Master: 接收客户端生产、消费请求。
• slave: 相当于副本节点，接收来自master的复制数据
• Master、slave之间使用Raft共识算法保证数据一致性，同一组master、slave之间自动故障切换。
• Broker: 负责接收和处理客户端发送过来的请求，以及对消息进行持久化，Broker内部三个节点互为主备。

3.2.1.4 分布式消息服务特点对比

• 备注: RabbitMQ中可以采用Firehose或者rabbitmq_ tracing插件实现持久化，但开启rabbitmq_tracing插件会影响性能，建议只在定位问题过程中开启.
• Kafka与RabbitMQ的性能方面差异: 消息中间件的性能主要衡量吞吐量，Kafka的吞吐量比RabbitMQ要高出1~2个数量级，RabbitMQ的单机QPS在万级别，Kafka的单机QPS能够达到百万级别。Kafka如果开启幂等、事务等功能，性能也会有所降低。

3.2.1.5 案例：通过Kafka构建实时交易分析平台

3.2.2 微服务引擎CSE

• 微服务架构模式通常包含如下内容:微服务之间的RPC通信、分布式微服务实例和服务发现、配置外置及动态、集中的配置管理、提供多种(熔断、隔离、限流、负载均衡等)微服务治理能力、分布式事务管理能力、调用链、集中日志采集和检索。
• 微服务架构模式通常包含如下内容:
  • 微服务之间的RPC通信。微服务架构模式要求微服务之间通过RPC进行通信，不采用其他传统的通信方式，比如共享内存、管道等。常见的RPC通信协议包括REST、gRPC等。使用RPC通信，能够降低微服务之间的耦合，提升系统的开放性，减少技术选型的限制。
  • 分布式微服务实例和服务发现。微服务架构特别强调架构的弹性，微服务设计般会遵循无状态设计原则;符合该原则的微服务扩充实例，能够带来处理性能的线性提升。当实例数很多的时候，就需要有一个支持服务注册和发现的中间件，用于微服务之间的调用寻址。
  • 配置外置及动态、集中的配置管理。随着微服务和实例数的增加，管理微服务的配置会变得越来越复杂。配置管理中间件给所有微服务提供统一的配置管理视图，有效降低配置管理的复杂性。微服务架构存在一些常见的故障模式，通过这些治理能;能够减少故障对于整体业务的影响
  • 分布式事务管理能力。常见的分布式事务处理模式包括Saga、TCC、无侵入式等。分布式事务管理可以降低处理分布式事务一致性问题的难度。
  • 调用链、集中日志采集和检索。查看日志仍然是分析系统故障最常用的手段调用链信息可以帮助界定故障和分析性能瓶颈。

3.2.3 适用场景

• 规划开发环境的目的是要保证开发人员更好的并行工作，减少依赖，减少搭建环境的工作量，降低生产环境上线的风险:
  • 搭建内网本地开发环境。本地开发环境的好处是各个业务/开发者可以搭建符合自己需要的最小功能集合环境，方便查看日志、调试代码等。本地开发环境能够极大的提升代码开发效率，减少部署和调试的时间。本地开发环境的不足之处是集成度不高，需要集成联调的时候，很难确保环境稳定。
  • 云上测试环境是相对比较稳定的集成测试环境。本地开发测试完成后，各个业务将本领域的服务部署到云上测试环境，并且可以调用其他领域的服务进行集成测试。根据业务规模的复杂程度，
  • 可以将云上测试环境进一步分为 （阿尔法）测试环境 （百塔）测试环境、（砝码）测试环境等，这些测试环境集成程度由低到高。一般 （砝码）测试环境 要求和生产环境一样的管理，确保环境稳定。
  • 生产环境是正式业务环境，生产环境需要支持灰度升级功能，支持在线联调和引流，保证升级故障对服务造成的影响最小化。
  • 云上测试环境可以通过开放CSE、中间件的公网IP，或者实现网络互通，这样可以使用云上的中间件替换本地环境，减少各个开发者自行安装环境的时间。这种情况也属于内网本地开发环境，微服务在本地开发环境的机器上运行。云上采用容器部署的微服务和本地开发环境机器上部署的微服务无法相互访问。为了避免冲突，云上测试环境只作为本地开发环境使用。

3.2.4 案例：华为消费者云服务微服务基础底座

• 微服务化和组件化，为大规模协同开发提供了技术基础，并为内部共享能力提供统的框架。到2021年初，应用市场已经开发300多个微服务，在现网部署10000多个实例。客户端共开发各种动态布局卡片500多个，组件化拆分出了100多个组件。
• AppGallery Connect:为开发者提供移动应用全生命周期服务，覆盖全终端全场景降低开发成本，提升运营效率，助力商业成功。

3.2.5 API网关

• 作为API提供者，可以将成熟的业务能力(如服务、数据等)作为后端服务，在API网关中开放API，并通过线下方式提供给API调用者使用，或者发布到API市场，实现业务能力变现。
• 作为API调用者，可以获取并调用API提供者在API网关开放的API，减少开发时间与成本。
• API网关帮助用户变现服务能力的同时，降低企业研发投入，让用户专注于企业核心业务，提升运营效率。例如，企业A在API网关中开放了电话号码归属地查询API，并发布到API市场。企业B通过API市场调用此API，并支付调用此API所产生的费用。此时，企业A通过开放业务能力，使自身服务能力变现，企业B直接调用企业A开放的API，减少开发时间与成本，最终实现企业间的共赢。

3.2.6 适用场景：API全流程研发体系高效率控制

• Swagger是一个规范且完整的框架，用于生成、描述、调用和可视化RESTful风格的Web服务。Swagger的目标是对REST API定义一个标准且和语言无关的接口，可以让人和计算机拥有无须访问源码、文档或网络流量监测就可以发现和理解服务的能力。

3.3 软件开发平台DevCloud

• 软件开发平台由以下几个主要服务构成:
  • 项目管理: 软件开发团队提供敏捷项目管理与协作，支持多项目管理、敏捷迭代管理、里程碑管理、需求管理、缺陷跟踪、多维度统计报表等功能
  • 代码托管:面向软件开发者的基于Git的在线代码托管服务，是具备安全管控成员/权限管理、分支保护/合并、在线编辑、统计服务等功能的云端代码仓库
  • 流水线: 提供可视化、可定制的交付流水线，缩短交付周期，提升交付效率
  • 代码检查:基于云端实现代码质量管理，软件开发者可在编码完成后执行多语言的代码静态检查和安全检查，并提供缺陷的分组查看与改进建议。
  • 编译构建:开发者提供配置简单的混合语言构建平台，实现编译构建云端化，支撑企业实现持续交付，提升交付效率。支持编译构建任务一键创建、配置和执行，实现获取代码、构建、打包等活动自动化，实时监控构建状态
  • 部署: 提供可视化、一键式部署服务，支持部署到虚拟机或者容器，提供Tomcat、SpringBoot等模板或者自由组装编排原子步骤进行部署，支持并行部署和流水线无缝集成，实现部署环境标准化和部署过程自动化。
  • 云测:面向软件开发者提供一站式云端测试平台，覆盖功能测试、接口测试融入DevOps敏捷测试理念，实现高效管理测试，保障产品质量。
  • 发布:为软件开发团队提供管理软件发布过程的能力，保障软件发布过程的规范化、可视化及可追溯。
  • CloudIDE: 云端开发环境。向开发者按需提供开发环境，支持完成环境配置编写、构建、运行、调试等操作，并支持对接多种代码仓库。
  • 开源镜像站: 由华为云提供的开源组件、开源操作系统及开源DevOps工具镜像站，致力为用户提供全面、高速、可信的开源组件/OS/工具下载服务。

3.3.1 应用全生命周期管理

• 全流程: 一个平台覆盖软件开发常用功能，软件开发各功能内嵌集成，对接治理&运维。
• 支持的编程语言和技术栈丰富:支持20多种主流编程语言:开发框架和运行环境，应用无缝迁移上云。
• 安全可信:安全测试、可信构建、高安全标准，7000+代码检查规则

3.3.2 CI/CD 全流程实现

• 从最初的 瀑布模型，到后来的 敏捷开发，再到今天的DevOps，这是现代开发人员构建出色产品的技术路线。随着DevOps的兴起，出现了持续集成，持续交付(CI/CD )和持续部署的新方法，而传统的软件开发和交付方式在迅速变得过时。过去的敏捷时代里，大多数公司的软件发布周期是每月、每季度甚至每年，而在现在DevOps时代，每周、每天甚至每天多次都是常态。当SaaS成为业界主流后尤其如此，可以轻松地动态更新应用程序，而无需强迫用户下载更新组件。很多时候，用户甚至都不会注意到正在发生变化。
• 持续集成注重将各个开发者的工作集合到一个代码仓库中，通常每天会进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。持续交付的目的是最小化部署或发布过程中团队固有的摩擦，它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布(理想情况下)。持续部署是种更高程度的自动化358无论何时代码有较大改动，都会自动进行构建/部署。

3.3.3 项目管理服务

• 项目是通过一定的流程，由w系列协同和受控的活动组成，项目的目标是满足特定需求，并受时间成本和资源的约束。项目管理通过对项目的过程和结果进行管理，达成项目的既定目标。看板项目属于项目的一种特有类型，看板依赖项目而存在，看板项目是将工作项层级、工作项类型和工作项通过看板直观展示。
• 专业的敏捷项目管理:基工敏捷的项目集合管理、单项目Scrum、精益看板。专业的产品规划:甘特图、思维导图，产品全景规划。
• 多维专业的报表: 多项目管理看板，仪表盘，报表
• 研发知识管理: 结构化知识，沉淀创新。
• 可信审计日志:1000+审计事件，全面溯源，安全可靠。
• 典型适用场景
  • 产品、开发、测试协同作战
  • 需求管理
  • 项目健康度 (进度、质量、风险、人员) 管理
  • 缺陷管理

3.3.4 代码托管服务

• 访问安全控制:提供保护分支、IP白名单等权鉴工具，保证特定权限账号+特定IP才能访问代码仓库
• 支持异地备份:支持有权限的用户一键将仓库备份到华为云的其它区域，其它物理主机与云主机。
• 仓库锁定:可手动锁定仓库，使其无法进行任何更改和提交，以预防即将发布的稳定版本遭到破坏。
• SSH部署秘钥:使用SSH密钥控制仓库读写权限，使用部署密钥开放仓库的只读权限误操追溯和恢复: 对于误删除的代码、分支等，可进行精确回滚或找回。对于删除的仓库，物理存储中有保留期备份。
• 操作日志:所有操作都带有Token，关键操作进行审计记录，审计日志被持久化，可保留足够长时间，可进行精确的5W1H回溯
• 规则设置:提供提交规则设置，合并评审&门禁设置等，使代码质量高度可控。
• 通知设置:仓库发生重要变更时，可向预先设置好的角色发送邮件、短信等通知。

3.3.5 代码检查服务和编译构建

• 自主研发:
  • 自主研发基于语法树、CFG的跨过程检查的代码检查引擎，支持C、C++、Java、
  • Python、Go等10种语言的代码检查
• 沉淀华为30年研发经验的高质量代码检查规则集:
  • 3000+代码检查规则，编程风格/编码安全/内存管理/输入校验/不安全函数/线程同步、代码重复率等20+代码检查规则场景
  • 兼容CWE/OWASP TOP 10/SANS TOP 25/MISRA/CERT等5+种安全编码标准。
• 自动化辅助缺陷修复:
  • 提供智能修复建议: 代码静态检查缺陷智能重构技术，自动/辅助开发修复软件缺陷，提升问题修复效率。
  • 提供Java编程规范缺陷修复能力;C/C++编程规范缺陷修复能力;Go代码自动修复能力。

3.3.6 自动化部署和发布服务

3.3.7 适用场景：软件及解决方案运营企业

• 推荐搭配: 项目管理、代码托管、代码检查、编译构建、部署、云测、发布。

3.4 应用管理与运维平台ServiceStage

• 为企业开发人员、测试人员、运维人员或项目经理等角色，提供应用托管、监控、告警和日志分析等能力，同时平台极具开放性，兼容业界主流应用技术栈，包括:多种语言，多种微服务框架和多种运行环境，能帮助企业极大地提升传统应用、Web应用微服务应用的管理与运维效率，聚焦面向行业的应用创新，从而提升企业竞争力。
• Spring Cloud:业界主流的开源微服务开发框架
• Spring-Cloud-huawei:Spring Cloud应用可通过使用spring-cloud-huawei托管到华为云上。
• ServiceComb:华为主导贡献给Apache的开源微服务框架

3.4.1 应用管理和微服务应用接入

• ServiceStaqe把相同VPC下的基础资源(如CCE集群、ECS等)加上可选资源(如ELBRDS、DCS等)组合为一个环境，如:开发环境，测试环境，预生产环境，生产环境环境内网络互通，可以按环境维度来管理资源、部署服务，减少具体基础设施运维管理的复杂性。
• Dubbo是阿里巴巴公司开源的一款开源高性能、轻量级的Java RPC服务框架，可以Spring框架无缝集成。

3.4.2 应用运维

• 实时图形化展示应用监控指标:CPU占用、告警、节点异常、运行日志、关键事件实时掌握。
• 微服务治理:支持微服务接口级SLA指标 ( 吞吐量、时延、成功率) 实时 (秒级) 监控和治理，保障应用运行不断服。

3.4.3 ServiceStage混合云微服务解决方案

• 解决方案&价值:
  • 应用托管: 传统应用、Web应用、微服务应用全生命周期托管，实现应用灰度发布和自动弹性。
  • 应用监控:应用运行状态可观测，可监可控，运维无忧。
  • 应用告警:告警信息多渠道实时递送，及时响应系统故障。
  • 应用日志:海量日志存储，秒级搜索，辅助问题定位和运营分析分布式事务处理: 非侵入&TCC双模支持，保证事务一致性

3.4.4 ServiceStage与其他云服务的关系

• ServiceStage实现了与源码仓库的对接(如DevCloud、GitHub、Gitee、GitLab、Bitbucket)，绑定源码仓库后，可以直接从源码仓库拉取源码进行构建
• 集成了软件中心，可以将构建完成的软件包(或者镜像包)归档对应的仓库和组织.
• 集成了相关的基础设施(如VPC、CCE、ECS、EIP、ELB )，在部署应用时可以直接使用已有或者新建所需的基础设施。
• 集成了微服务引擎，进入ServiceStage控制台可以进行微服务治理相关的操作。
• 集成了应用运维管理及应用性能管理服务，可以进行应用运维及性能监控相关的操作。
• 集成了存储、数据库、缓存等服务，通过简单配置即可实现数据持久化存储。

3.4.5 适用场景：通过ServiceStage进行微服务构建

• 随着业务增长，服务会遇到各种意外情况，如:瞬时大规模并发访问、服务出错、入侵等情况。使用微服务架构可以对服务做细粒度管控，支撑业务需求,
• ServiceStage提供了业内领先的微服务应用解决方案，具有以下优势
  • 支持原生ServiceComb、Spring Cloud、Dubbo和Service Mesh多种微服务框架支持双栈模式(SDK和服务网格互通)，无需更改业务代码直接托管上云
  • 支持基于Swagger的API管理。
  • 支持多语言微服务，如JAVA、Go、Nodejs、PHP、Python等。
  • 提供服务中心、配置中心、仪表盘、灰度发布等功能。
  • 提供容错、限流、降级、熔断、错误注入、黑白名单等全套微服务治理策略。可针对业务场景进行界面化操作，极大提高了服务治理的可用性。

思考题