微服务的概念

传统单体大项目的缺点：

• 系统较大、较复杂，开发难度大
• 部署速度慢
• 难以升级、维护

微服务是一种架构风格，将一个大项目拆分为多个小的、独立的微服务（功能单元）。

微服务的特点：

• 小：微服务是体积较小的功能单元，将一个大项目拆分为多个微服务
• 独：服务都是独立的，运行在单独的JVM进程中，需要单独部署、维护，服务可以使用不同的编程语言来写，可以使用不同的数据库。每个服务往往都要做集群（节点数视该服务的访问量而定）。
• 轻：服务之间的通信机制是轻量级的
• 松：服务之间是松耦合的

微服务的优点：

• 易于开发、维护，扩展性好
• 启动快，修改局部无需重新部署整个项目
• 技术栈不受限制

 使用微服务时，可以针对性地设置集群大小，比如电商网站，商品、订单模块负载大，集群节点多些；积分模块负载小，集群节点少些。

微服务的缺点：

• 要部署、维护多个服务（服务治理），运维难度加大。
• 单体应用使不使用分布式都行，微服务一般都要使用分布式，对开发人员的技术要求较高
• 调整接口成本高，需要同时修改调用它的其它微服务
• 代码重复多。单体应用把要重复调用代码封装为工具类，项目中直接调用即可；每个微服务都是独立的，不能调用其它微服务中的类，需要把要用的类copy到要本服务中。
• 事务难度增加，要使用分布式事务。比如购买商品获赠积分，订单服务创建订单+积分服务增加积分，这是一个事务，但不在同一个应用中，使用事务难度增大。

微服务的拆分与设计

如果项目拆分过粗，那和单体应用差不多；如果拆分过细，则服务太多，管理难度大，服务调用开销大。

拆分的大原则：一个模块不依赖、或极少依赖其它模块，但需要给多个模块、客户端提供数据（一般2个或2个以上）。

微服务的设计原则：

• 单一职责：每个服务只管本模块的业务，不处理其他模块的业务。
• 服务自治：每个服务都是单独的，单独进行开发、测试、部署。
• 轻量级通信：服务之间的通信要是轻量级的、跨平台、跨语言，这样可以让服务的开发不收技术种类限制。
• 接口明确：服务之间往往要相互调用，设计服务之间的接口时，要将接口设计得通用些、考虑全面些，后续维护、升级时不轻易修改接口。

服务消费者、服务提供者

eg.用户服务调用订单服务，用户服务是服务消费者，订单服务是服务提供者。

常用的微服务框架

• Spring Cloud
• Dubbo    阿里巴巴的开源框架，现在由Apache维护

前台如何访问、调用微服务？

比如查询订单信息，要访问订单的微服务，有时候需要访问多个微服务。

微服务部署在不同的服务器上，一般是无状态的，不保存用户的状态信息（比如是否已登录），需要找一个地方来保存用户的状态信息、检查用户权限。

一般要通过API Gateway来访问微服务。

API Gateway，其实就是一个代理，代理所有微服务，请求交给API Gateway，由API Gateway调用相应的微服务来处理。

API Gateway提供统一的接口，供前台调用，并保护用户状态、检查用户权限。

API Gateway只是一个称谓，有多种实现：可以是MVC框架，可以是node.js服务器，也可以是其它的。

SpringCloud使用Eureka作为服务注册中心，Dubbo使用Zookeeper作为服务注册中心，服务节点、注册中心之间通过心跳机制动态维护服务节点状态。

微服务的一些概念

• 网关   路由转发+过滤器。比如请求订单服务，网关将请求路由转发给注册中心，注册中心选择一个订单服务的节点来处理。可以在网关处对请求做一些处理，比如验证用户是否登录，实现过滤功能。
• 服务注册发现
• 负载均衡器。通常有多个节点提供同一个服务，需要用负载均衡器确定转发给哪个节点处理
• 配置中心。节点太多，需要一个配置中心统一管理各节点的配置，方便运维。
• 链路追踪。一个业务可能需要调用多个服务来完成，比如下单：订单服务 -> 用户服务、商品服务 -> 支付服务，服务调用形成了一个链路
• 熔断  保护服务节点本身、被调者，提升容错、可用性。

服务之间如何相互调用？

• REST

基于HTTP，简单灵活，跨语言、跨客户端（只要SDK封装HTTP就可以调用），应用广泛，SpringCloud使用的就是REST。

http的数据包大，可以携带更多的数据。

• RPC

远程过程调用，过程及即方法，远程调用其他服务中的方法，就像调用本地方法一样。

客户端、服务器之间建立TCP连接，安全可靠，连接可复用。

rpc数据包小，传输更快，支持同步调用、异步调用，Dubbo使用的就是RPC。

同步调用：调用服务时，当前线程阻塞，调用完成（返回结果）才继续往下执行

异步调用：调用服务时，当前线程继续往下执行，调用完成（返回结果）时自动调用回调函数处理返回的数据

服务的注册、发现

通常要把一个服务拷贝一下，部署到多个服务器上，实现服务的集群、分布式。访问量大的服务集群节点布置多些，访问量小的服务集群节点可少些。

运行过程中，一些服务器可能会下线，负载大的时候也会增加节点（服务器），节点会变化，要发给哪个节点来处理？

找到、发现某个节点，使用这个节点来处理请求，所以叫做服务发现，常用的技术有Zookeeper、Eureka。

服务提供者（各服务节点）把信息（本机地址、所提供的的服务）注册到Zookeeper或Eureka上，并使用心跳实时更新信息。

Zookeeper、Eureka根据这些注册信息、调用特定算法来计算，确定要调用哪个节点来处理请求，即发现一个服务。

访问量上升的处理

访问量上升，对某一服务的调用增加，如果不加处理，节点负载太大，会影响所有调用此服务的前台。

常用的处理方式：

• 重试机制
• 限流
• 熔断机制
• 负载均衡
• 降级（本地缓存）

Dubbo、SpringcCloud的对比

Dubbo

• 通信方式：rpc  性能高
• 注册中心：Zookeeper

SpringCloud

• 通信方式：http   restful风格
• 注册中心：Eureka
• 配置中心：Config
• 断路器：Hystrix
• 网关：Zuul
• 分布式链路追踪：Sleuth+Zipkin

Dubbo很多功能都没有，为什么还有很多公司在使用Dubbo？

因为Dubbo的性能比SpringCloud要高很多，dubbo使用rpc通信，SpringCloud使用http、restful通信，http连接3次握手、4次挥手，很花时间；并且Dubbo板块少，简单一些，开发速度快。

SpringCloud组件多，功能更齐全，但开发起来慢一些，性能低一些。

如果项目对性能要求较高，优先考虑dubbo。