微服务入门
为什么需要微服务？
第一阶段：单体模式 传统的单体模式是通过增加tomcat服务器，并且通过Ngnix来实现负载均衡， 从而实现了水平拓展。 这样弊端：
- a.应用复杂度增加，更新、维护困难
- b.易造成系统资源浪费
- c.影响开发效率
- d.应用可靠性低
- e.不利于技术更新
第二阶段：SOA 面向服务框架
SOA将原来的单体架构按照功能细分不同的子系统，然后再由各个子系统依赖服务中间件来调用所需的服务。 ESB：服务中间件，这里指企业服务总线。
优点：
- a.提高了开发效率
- b.业务拆分，降低了模块之间的耦合度
- c.提高了程序的重用性
- d.便于了程序的拓展
缺点：
- 并没有解决单体模式随着功能的增多，服务会变得复杂的问题。
第三阶段：微服务 微服务架构是一种架构风格和架构思想，它提倡将系统业务按照功能拆分为更加细粒度的服务，即每一个服务都是一个独立的应用。这些应用对外提供公共API用于应用调度。
总结： RPC:远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 即解决了2个问题：
- 解决分布式系统中，服务之间的调用问题。
- 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
优势：
- 1.复杂度可控
- 2.可独立部署
- 3.技术选型灵活
- 4.易于容错
- 5.易于拓展
- 6.功能特定，相互关联度低
不足：
- 1.分布式的创建和测试有一定的难度
- 2.部署较为复杂
- 3.多服务相对来说消耗内存
微服务与SOA的区别
微服务的应用场景：
- 1.未来有一定的扩展复杂度，而且有很大用户增量预期的应用（新兴互联网公司）
- 2.那些项目规模很大、业务复杂度较高，而且需要长期跟进的项目
服务拆分的建议：
- 1.通过业务功能分解
- 2.将域驱动设计分解多个子域 （域驱动是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。）
- 3.按照动词或者用力分解
- 4.通过一个给定类型的实体或者资源来分解
微服务的组件： 服务注册中心：注册系统中所有服务的地方。 服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便找到自己。 服务发现：服务调用方从服务注册中心找到自己所需要调用服务的地址。 负载均衡：服务提供方一般以多例的方式提供服务，使用负载均衡能够让服务调用方找到合适的服务节点。 服务容错：通过熔断器等一系列服务保护机制，保证服务调用者在调用异常服务时快速地返回结果，避免了大量地同步等待。 服务网关：也称API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。 分布式配置中心：将本地化的配置信息注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包迁移
补充： 熔断器：通常用于无状态在线交易系统。 重试机制：当触发熔断失败时，阶段抖动后（避免立刻重试）进行重试操作。
