微服务架构攀登之路（一）之微服务初识
一、认识微服务
1. 行业背景
⚫ 不同行业 IT 系统更新频率
⚫ IT 系统存在的问题
⚫ 微服务架构在企业中应用情况
⚫ docker 在企业中的使用情况（容器）
2. 什么是微服务
⚫ 使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化的方式部署
⚫ 什么叫微？
◼ 代码量少？
◼ 开发时间少？
◼ 微是设计思想
3. 微服务的特点
⚫ 单一职责：独立的业务单独放在一个项目里，比如订单服务作为一个项目
⚫ 轻量级的通信：http，rpc，非轻量级（例如 java 的 RMI）
⚫ 隔离性：每个服务相互隔离，不干扰
⚫ 有自己的数据
⚫ 技术多样性
4. 微服务诞生背景
⚫ 互联网行业的快速发展，需求变化快，用户数量变化快
⚫ 敏捷开发深入人心，用最小的代价，做最快的迭代，频繁修改、测试、上线
⚫ 容器技术的成熟，是微服务的技术基础
5. 互联网架构演进之路
⚫ 单体架构
◼ 所有功能集成在一个项目中
◼ 项目整个打包，可以部署到服务器运行
◼ 应用与数据库可以分开部署，提高性能
◼ 优点：
◆ 小项目的首选，开发成本低，架构简单
◼ 缺点：
◆ 项目复杂之后，很难扩展和维护
◆ 扩展成本高，有瓶颈
◆ 技术栈受限
⚫ 垂直架构
◼ 对于单体架构的拆分，大项目拆成单个的项目结构
◼ 存在数据冗余
◼ 项目之间要处理数据同步，通过数据库同步
◼ 优点：
◆ 小项目的首选，架构简单
◆ 避免单体架构的无限扩大
◆ 技术不再受限了
◼ 缺点：
◆ 很多功能放在一个工程中，有一定瓶颈
◆ 系统性能扩展要通过集群结点扩展，成本
⚫ SOA 架构（面向服务的架构）
◼ 将重复性的功能进行抽取，抽取成对应的服务
◼ 通过 ESB 服务总线去访问
◼ 优点：
◆ 提高系统可重用性
◆ ESB 减少系统接口耦合问题
◼ 缺点：
◆ 系统与服务界限模糊，不利于开发
◆ ESB 服务接口协议不固定，不利于系统维护
◆ 抽取粒度较大，有一些耦合性
⚫ 微服务架构
◼ 将服务层一个一个抽取为微服务
◼ 遵循单一原则
◼ 微服务之间采用一些轻量协议传输数据
◼ 优点：
◆ 服务拆分粒度非常细，利于开发
◆ 提高系统可维护性
◆ 比 ESB 更轻量
◆ 适用于互联网更新换代快的情况
◼ 缺点：
◆ 服务过多，服务治理成本高
◆ 开发技术要求更高
6. 微服务架构图
⚫ 假设做一个商城网站
◼ 用户可以登录和注册，发短信验证
◼ 管理员可以查看商品，对商品增删改查
⚫ 传统访问方式如下：
⚫ 微服务架构访问方式：
⚫ 添加 ApiGeteway，对客户端暴露一套 API，方便调用
7. 微服务架构的优势
⚫ 独立性
⚫ 使用者容易理解
⚫ 技术栈灵活
⚫ 高效团队
8. 微服务架构的不足
⚫ 额外的工作，服务的拆分
⚫ 保证数据一致性
⚫ 增加了沟通成本
二、微服务需要考虑的问题
1. 微服务如何通信
⚫ 从通信模式考虑
|
|
一对一 |
一对多 |
|
同步 |
最常见 |
|
|
异步 |
通知-请求异步响应 |
发布订阅-发布异步响应 |
⚫ 从通信协议考虑
◼ RPC
2. 微服务如何发现彼此
⚫ 传统服务如下：
⚫ 一般是 IP：端口号访问
⚫ 微服务服务发现有 2 种方式——客户端发现和服务端发现
⚫ 客户端发现：微服务启动后，将自己 IP 和端口进行注册，客户端查询注册，得到提供服务的 IP和端口，通过负载均衡，访问微服务
⚫ 服务端发现：客户端访问时，不去注册中心了，通过服务发现代理去直接访问
3. 微服务如何部署、更新和扩容
⚫ 微服务部署到 docker 容器
⚫ 涉及服务编排：K8S，swarm
