这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
写在开头
本人是一个第一次参加字节青训营的学生，主要是简单记录一下自己学习的过程以及复习（详细的需要自己去看每天对应的课程），每天会发前一天课程的笔记或者是自己的思考
系统架构的演进历史
互联网规模大，发展快，需求复杂，人员增加，所以系统架构不断演进。
-
单体架构
- All in one process
-
垂直应用架构
- 按照业务线垂直划分
-
分布式架构
- 抽出与业务无关的公共模块
-
SOA架构
- 面向服务
-
微服务架构
- 彻底的服务化
微服务架构概览以及优缺点
微服务架构区别于传统的单体软件架构，是一种为了适应当前互联网后台服务的「三高需求：高并发、高性能、高可用」而产生的的软件架构。
优点：
- 微服务是继SOA后，最流行的服务架构风格之一。
- 按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。
- 微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。
缺点：
- 与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反
- 在国内外的技术社区中，比较推崇现有开源方案，如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。
- 已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。
微服务架构的三大要素
-
服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
-
可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
-
安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
微服务架构原理及特征
微服务架构中的基本概念及组件
-
服务
- 一组具有相同逻辑的运行实体
-
实例
- 一个服务中的每个运行实体
-
实例与进程的关系
- 没有必然对应关系，一般一对一或者一对多
-
常见的实例承载形式
- 进程、VM、k8s pod......
-
集群
- 服务内部逻辑划分，包含多个实例
-
有/无状态服务
- 服务实例是否存储了可持久化数据
服务间通信
- 微服务之间通过网络进行通信
- 常见的通信协议包括 HTTP、RPC
服务注册及服务发现
服务发现的发现机制主要包括三种：
服务提供者：服务启动时将服务信息注册到注册中心，服务退出时将注册中心的服务信息删除掉。
服务消费者：从服务注册表获取服务提供者的最新网络位置等服务信息，维护与服务提供者之间的通信。
注册中心：服务提供者和服务消费者之间的一个桥梁
服务发现机制的关键部分是注册中心。注册中心提供管理和查询服务注册信息的API。当服务提供者的实例发生变更时（新增/删除服务），服务注册表更新最新的状态列表，并将其最新列表以适当的方式通知给服务消费者。目前大多数的微服务框架使用Netflix Eureka、Etcd、Consul或Apache Zookeeper等作为注册中心。
为了说明服务发现模式是如何解决微服务实例地址动态变化的问题，下面介绍两种主要的服务发现模式：
客户端发现模式服务端发现模式。客户端模式与服务端模式，两者的本质区别在于，客户端是否保存服务列表信息。
