博客:cbb777.fun
全平台账号: 安妮的心动录
github: https://github.com/anneheartrecord
下文中我说的可能对，也可能不对，鉴于笔者程度无限，请君自辨。有问题欢送大家找我探讨
云原生 & 微服务
近年来微服务与云原生、CI/CD 这些概念被炒得很火，少数利用都会说本人利用了“云”资源，是一个云原生架构的利用。那么云原生到底是什么呢，或者说应用了什么样的技术的利用能力被称之为云原生利用呢？
云计算的衰亡
首先云原生是和云计算分不开的，这里的云计算更多的指的是一种云上的资源，而云呈现之前，市场还处在一个物理机时代，如果要启用一个新的利用，就得本人搭一台新的服务器，始终到 2001 年 VM 呈现了，通过虚拟机能够在一台服务器上跑多个虚拟机来缩小服务器的数量（同时也是缩小了企业堆机子的钱）
而在虚拟化技术成熟之后，云计算才正式呈现，第一个搞云的公司是 AWS，在 2008 年证实了云计算是可行业务
云计算出租的模式有三种
IaaS:Infrastruture As A Service(基础设施及服务)，是云服务的最底层，次要提供一些根底资源，比方服务器、存储和网络。咱们惯例用的云服务器就属于 IaaS
PaaS:Platfrom as a Service（平台即服务），提供商为企业搭建网络基础设施及软件、硬件平台，将软件开发、治理、部署都交给第三方，开箱即用。除了底层的服务器之后，通常还具备相应的性能接口，比方阿里云能够给视频主动转码，给视频减速进步清晰度等、图床等等
SaaS:Software as a Service(软件即服务)，开发者只须要关注本人的业务逻辑，不须要关怀底层。应用这一层的云计算资源甚至不须要开发人员，供应商间接提供一站式服务。
Maas: Modle as a Service(模型即服务)，这是大语言模型呈现之后提出的一个概念，即你只须要创立对应的模型，大语言模型来替你实现，目前还只是个概念
炽热的微服务
在咱们开发一个应用服务时，有很多种架构供咱们抉择，而这些架构依照历史的工夫线来看的话，其实能发现它们是在一直向低耦合，高性能，麻利开发、疾速公布、高度自治化这几个方面一直聚拢的
单体利用
单体利用通常是一个宏大的文件，部署在一台机器上，高耦合，对性能批改通常须要牵一发而动全身，想要加强单体利用的性能个别只能堆机子，一直减少服务器的数量
分层架构
最典型的就是 MVC 和 MSC 架构，别离是 model view controller 和 model service controller 的缩写，随着时代的倒退，人们发现单体利用很难抗住大流量，于是分层架构诞生了。分层架构就是将单体利用进行垂直分层，耦合仍旧大，我的项目之间的接口大多数为数据同步，是一种很简略的架构。开发疾速，通过垂直拆分之后我的项目不至于太大，每一层能够应用不同的技术。
SOA 面向服务架构
当垂直架构的利用越来越多，就会呈现多个利用都依赖的业务组件，比方数据库，而且各个利用交互越来越频繁，此时就须要把局部通用的组件拆分独立解决，于是 SOA 面向服务架构诞生了，它带来了模块化开发、分布式拓展部署和服务接口定义等概念。
SOA 须要建设企业服务总线，内部利用通过总线调用服务，有以下特色：可从企业内部拜访、随时可用、标准化的服务接口等。个别是大型企业才思考应用 SOA 架构。
当业务总线崩掉，所有的服务都会挂掉。能够说业务总线的吞吐量决定着整个零碎的下限。
微服务架构
在汲取了 SOA 的思维之后，微服务诞生了，它具备以下特点
- 服务层齐全独立 并将服务层抽离为一个个的微服务
- 遵循繁多准则
- 应用 RESTful 等轻量协定进行通信
- 个别应用容器技术进行部署 运行在本人的独立过程中
架构如图：
在微服务架构下服务的拆分粒度更细小，有利于资源的反复利用，进步开发效率，采纳去中心化思维，更加轻量级
毛病：如果服务实例过多，那么治理老本就会很大，不利于保护；且服务之间相互依赖，可能造成简单的依赖链条，往往单个服务异样，其余的服务也会受到影响
在理论开发中个别通过 DDD 的思维对微服务进行拆分，既不能让服务实例太多（不好治理、部署老本大、调用关系简单），也不能让服务实例太少（每个服务量级都很大，高度耦合），个别是通过各个服务的作用域进行划分。
微服务与 SOA 的区别：
微服务继承了 SOA 的泛滥长处和理念
SOA 更适宜与许多其余应用程序集成的大型简单企业应用程序环境，小型的利用并不适宜 SOA。
微服务则更适宜于较小和良好的宰割式 web 业务零碎，在微服务架构中没有 SOA 中的 ESB 进行集中化治理，而是通过轻量级通信机制互相沟通。
SOA 尝试采纳中心化治理来确保每个利用之间可能协同运作，而微服务则尝试部署新性能。疾速无效的拓展开发团队，重视于扩散治理、代码再利用与自动化执行
支流的微服务框架
Java:Spring Cloud 和 Dubbo
Go:Go-kit 与 Go-Micro
Go-Kit:
是一个 Go 语言工具包的汇合，提供了实现系统监控和弹性模式组件的库，比方日志记录、跟踪、限流、熔断等。
基于 Go-Kit 的应用程序架构由三个次要局部组成：传输层、接口层和服务层
传输层：网络通信，通常应用 HTTP 或者 grpc 等网络传输方式，Go-Kit 还反对应用 AMQP（提供同一音讯保护的应用层协定）和 Thift（接口描述语言与二进制通信协定）等多种网络通信模式
接口层：服务器和客户端的根本构建块，在 Go-kit 中的每个对外提供的接口办法都会被定义成一个端点，以便在服务器和客户端之间进行网络通信
服务层：具体的业务逻辑实现，业务逻辑包含外围业务逻辑
Go-Micro
基于 Go 实现的插件化 RPC 微服务框架，提供了服务发现、负载平衡、同步传输、异步通信以及事件驱动等机制，尝试弱化分布式系统间的通信，让开发者能够专一与本身业务逻辑的开发
设计哲学：可插拔式的架构理念，提供可疾速构建微服务零碎的组件
Go-Micro 组件
- registy : 服务发现组件 解析服务 name 至服务地址 反对 consul etcd zookeeper dns 和 gossip 等组件
- selector: 基于 registry 的客户端负载平衡组件 client 应用 selector 组件从 registry 返回的服务列表中进行负载平衡抉择
- broker: 公布和订阅组件 服务之间基于消息中间件的异步通信形式 个别应用 MQ 比方 kafka rabbitMQ 等等
- transport: 服务之间同步通信形式
- codec: 服务之间音讯的编码和解码
- server: 服务主体 该组件基于下面的 registry selector transport 和 broker 组件，对外提供一个同一的服务申请入口
-
client: 提供微服务的客户端
微服务六大准则
1. 高内聚 低耦合 每个服务是针对于一个繁多职责业务能力的封装 服务之间通过轻量级的通信形式进行通信
2. 高度自治 每个服务可能独立部署并运行在独立的过程内 技术选型灵便 适合的业务问题能够抉择适合的技术栈 服务与服务之间采取与语言无关的网络通信进行交互 也就是说服务之间能够用不同的语言、不同的版本、不同的工具、在不同的零碎上运行
3. 以业务为核心 每个服务代表了特定的业务逻辑 有显著的边界上下文
4. 弹性设计 可容错、具备自我爱护能力的零碎，服务之间互相隔离，限度应用资源，避免级联的服务雪崩谬误
5. 日志与监控 必须用分布式日志零碎进行日志的治理 不然每个微服务单独具备各自的日志 查找起来会很麻烦 监控各个服务的性能 比方 Prometheus，进行资源的弹性化扩张与膨胀
6. 自动化(drone)
云原生技术及十二因素
当初对于云原生的定义通常是：有利于各组织在私有云、公有云与混合云等新型动静环境中，构建和运行可弹性拓展的利用，代表技术有容器、服务网格、微服务、不可变基础设施即申明式 API
云原生的基础架构
- 微服务：每个服务被独立部署，服务之间松耦合，这样就能够独立对每个服务进行降级、部署、拓展和重启，具备升高零碎复杂度。独立部署，独立扩大和跨语言编程等长处。同时对于运维来说，难度晋升，并且整个分布式系统变得更简单，须要大量的测试机部署。还须要思考网络提早、容错性、音讯序列化和不牢靠网络等等
- 容器：轻量级的虚拟化技术，可能在繁多主机上提供多个隔离的操作系统环境，通过一系列的 namespace 进行过程隔离，容器分为运行时和编排两层，运行时负责容器的计算、存储、网络等，编排层负责容器集群的调度，服务发现和资源管理。另外，仅仅有容器还是不够，这样的话运维部署老本太大，为了解决容器的治理和调度问题，又引入了 Kubernetes(在 1.20 版本 Kubernetes 正式摈弃 docker)，能够实现容器化的自动化部署、自动化扩容缩容和保护等性能
- 服务网格（service mesh)次要有侵入式架构和非侵入式架构，侵入式指的是服务框架嵌入程序代码，开发者组合各种组件，如 RPC、负载平衡。熔断等，实现微服务架构。非侵入式次要是以代理的模式和应用程序部署在一起，开发者只须要关注本身业务即可。service mesh 使得零碎架构的技术栈下移，解耦了应用程序的监控、追踪和服务发现。相干软件包含 istio linkerd 等，同时为了让 service mesh 有更好的底层撑持，咱们又将 servise mesh 运行在 kubernetes 上
- DevOps: 蕴含了开发、测试和运维第三个局部，由一个团队负责，一直的更新迭代，推动产品的开发过程，能够实现疾速开发与疾速部署
- 申明式 API：Kubernetes 的能力都是通过各种 API 来提供的，所谓的申明式 API，就是会编写对应的 API 对象的 YAML 文件交给 Kubernetes，而不是间接应用一些命令来操作 API，这个 YAML 文件其实就是一种申明，而一个个提交命令，则是命令式 API。通常申明式 API 具备以下特点：1. 蕴含绝对大量的绝对较小的对象。2. 这些对象定义应用程序或者根底构造的配置。3. 对象绝对更新不频繁
-
不可变基础设施：在传统的可变基础设施（服务器）中，服务器会一直的更新和批改，这类设施的管理员能够手动降级或者降级软件包版本，调整服务器的配置，这样的服务器咱们认为是可变的。他们能够在创立后批改。不可变基础设施就是另一种基础设施模式，其中的服务器在部署之后永远不会批改，如果须要以任何形式更新、修复或者批改默写内容，须要先对公共镜像进行批改，而后利用镜像构建新服务器来替换旧服务器，验证之后新的服务器会投入使用，旧的服务器会被下掉。不可变基础设施能提供更高的一致性和可靠性，更简略、更可预测的部署过程。二者被比作宠物和牛，过来咱们将服务器当做宠物，如果倒下了那么服务就无奈运行，而在新的形式中，服务器被编号，就像一群牛
云原生十二因素
云原生的 12 因素是晓得开发者如何利用云平台来构建更具可靠性和扩展性，更易保护的云原生利用
1.CodeBase: 根底代码，一份基准代码，多份部署，用一个代码库进行版本控制和应用程序的屡次部署
2.Dependencies: 显示申明依赖关系，应用程序通过适当的工具隔离依赖性
3.Config: 配置文件，在环境中存储配置
4.Backing Services: 后端服务，把后端服务当做附加资源（很宝贵的资源），数据库、音讯队列、换出零碎都被当做附加资源在不同环境中被等同的调用。据说当初很多大厂都不会间接操作数据库了，咱也不晓得具体是怎么实现的，数据存在哪里。
5.Build release run: 构建、公布、运行 严格拆散架构和运行
6.Processes: 以一个或多个无状态过程运行利用，任何须要长久化的数据都被存储在后端服务中
7.Port binding: 端口绑定，通过端口绑定提供服务
8.Concurrency: 并发，通过过程模型进行拓展
9.Disposability: 易解决、疾速启动和优雅终止
10.Dev/pro parity: 开发环境与线上环境等价，尽可能放弃开发、预公布和线上环境的相似性
11.Logs: 将日志当做事件流，容许执行环节通过集中式服务来收集、聚合和检索剖析日志
12.Admin processes: 治理过程，后盾治理工作当做一次性过程运行
12 因素曾经提出很久了，有局部因素曾经无奈跟上时代的倒退，只能作为参考
现如今的技术更迭是十分十分快的，很多货色作为学生你刚据说，感觉很新鲜想去学，可能企业曾经用过很久，甚至业界曾经有更优的计划，把这个技术摈弃了。也有局部后端开发者自嘲道，这个货色我还没学，人家就不必了。因而，我倡议大家不论什么技术，你如果感兴趣就先上手，对着官网文档看，其实任何高级、难的技术如果仅仅只是上手的话往往花不了太多工夫。
本文由 mdnice 多平台公布