微服务简介
微服务的概念
传统单体大项目的缺点：
- 系统较大、较复杂，开发难度大
- 部署速度慢
- 难以升级、维护
微服务是一种架构风格，将一个大项目拆分为多个小的、独立的微服务（功能单元）。
微服务的特点：
- 小：微服务是体积较小的功能单元，将一个大项目拆分为多个微服务
- 独：服务都是独立的，运行在单独的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。
