微服务架构攀登之路（一）之微服务初识

一、认识微服务

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