微服务的理解
一.体积小，轻量级的功能开发
二.为什么要使用微服务
1.单片应用程序庞大而复杂
2.单片应用程序是持续部署的障碍
3.当不同模块具有相互冲突的资源需求时，单片应用程序也难以扩展
4.单片应用程序使得采用新框架和语言变得极其困难
5.微服务解决复杂性，多模块开发，每个后端服务都公开一个REST API使其调用
6.每项服务都能够由专注于该服务的团队独立开发
7.微服务架构模式使每个微服务能够独立部署
8.微服务架构模式是每个服务可以独立扩展
三.微服务构建-API网关
1.使用
API网关负责请求路由，组合和协议转换。使用统一服务入口
API网关为每个客户端提供自定义API。(Netflix API网关)
2.优点和缺点
优点是封装了应用程序的内部结构，客户端只需与网关通信，而不必调用特定服务，减少了客户端与应用程序之间的往返次数，简化了客户端代码 缺点是必须开发，部署和和管理的高可用组件，需更新API网关才能更新每个微服务端点
3.实现API网关
基于微服务的应用程序是分布式系统，必须使用进程间通信机制 需要知道与之通信的每个微服务的位置(IP地址和端口)。 需要使用系统的服务发现机制
四.微服务构建-进程间通信
1.交互风格
一对一：每个客户端请求仅有一个服务实例处理（通知）
一对多：每个请求有多个服务实例处理（发布/订阅）
同步：客户端期望服务及时响应，甚至可能在等待时阻塞
异步：客户端在等待相应时不会阻塞，并且相应不一定立即发送
2.定义API
API定义的性质取决于你使用的IPC机制，如果你使用消息传递，则API由消息通道和消息类型组成，如果你使用HTTP,则API由URL以及请求和相应格式组成。
3.IPC技术
基于HTTP的REST或Thrift等基于请求/响应的同步通信机制 异步的，基于消息的通信机制，例如AMQP或STOMP， 基于文本的格式，例如JSON或XML
五.微服务架构中的服务发现
1.客户端发现模式
客户端负责确定可用服务实例的网络位置以及跨平台的负载平衡请求。客户端查询服务注册表，该服务注册表是可用服务实例的数据库。然后，客户端使用负载平衡算法选择一个可用的服务实例并发出请求。
2.服务端发现模式
客户端通过负载均衡器向服务发出请求，负载均衡器查询服务注册表并将每个请求路由到可用的服务实例
3.服务发现和注册
Netflix Eureka ，它提供了REST API，用于注册和查询服务实例。服务发现的关键部分是服务注册表。服务注册表是可用服务实例的数据库。服务注册表提供管理API和查询API。使用管理API在服务注册表中注册和注销服务实例
服务发现的两种模式图（引用）
六.微服务的事件驱动数据管理
1.微服务与分布式数据管理
单片应用程序具有单个数据库，可使用ACID事务，
原子性-以原子方式进行更改
一致性-数据库的状态始终一致
隔离性-即使事务同时执行，他们也会以串行方式执行
持久性-一旦交易提交，它就不会撤销 可以简单地开始事务，更改（插入，更新和删除）多行，并提交事务。
而在微服务架构上，每个服务都维护一个私有数据库，例如order和customer表对其各自的服务是私有的，则订单无法直接访问customer表，只能使用客户端提供的API
2.基于事件驱动的架构
微服务通过Message Broker交换事件，实现跨多个服务的业务事务，并提供最终的一致性。
使应用程序能够维护物化视图。 实现事件驱动架构是如何以原子方式更新状态以及如何发布事件：数据库用作消息队列，事务日志挖掘和事件源
七.选择微服务部署策略
1.每个主机模式的多个服务实例
该模式的几种变体，一是每个服务实例是进程或进程组，例如：java服务实例部署为Apache tomcat服务器上的web应用程序。二是在同一进程或进程组中运行多个服务实例，例如 可以在同一个tomcat服务器上部署多个web应用程序。 一个主要的好处是它的资源使用相对有效。另一个好处是部署服务实例的速度相对较快
2.每个主机模式的服务实例
可以在其自己的主机上独立运行每个服务实例，此模式有两种不同的特殊化：每个虚拟机的服务实例和每个容器的服务实例
1> 每个虚拟机的服务实例 前者将每个服务打包为虚拟机（VM）映像，每个服务实例都是使用该VM映像启动的VM,这是Netflix用于部署其视频流的主要方法，优点每个服务实例完全隔离运行和封装了你的服务的实现技术；缺点构建慢，无差别的繁重工作
2> 每个容器的服务实例 每个服务实例都在其自己的容器中运行，容器是操作系统级别的虚拟化机制。容器由在沙箱中运行的一个或多个进程组成。它们有自己的端口命名和根文件系统，要使用此模式，请将服务打包为容器映像。容器映像是由运行服务所需的应用程序和库组成的文件系统映像。 3> 容器与VM的区别 容器类似于VM的好处，将服务实例隔离，容器不如VM安全，容器通常部署在具有每VM定价的基础架构上
八.将Monolith重构为微服务
1.重构到微服务的概述
构建一个由微服务组成的新应用程序，并将其与您的单一应用程序一起运行，单片应用程序实现的功能量会缩小，直到它完全消失或者变成另一个微服务。
1>策略1 停止挖掘
调用monolith提供的远程API 直接访问monolith的数据库 维护自己的数据副本，该数据与monolith的数据同步
2>策略2 拆分前端和后端
表示层-处理http请求并实现（REST）API 或基于HTML的web UI的组件，在具有复杂用户界面的应用程序中，表示层通常是大量代码 业务逻辑层-作为应用程序核心并实现业务规则的组件 数据访问层-访问基础架构组件（数据库和消息代理）
3>策略3 提取服务
将整体内的现有模块转变为独立的微服务。每次提取模块并将其转换为服务时，monolith都会缩小。一旦你转换了足够的模块，巨石将不再是一个问题。它要么完全消失，要么变得足够小以至于它只是另一种服务。
九.*** 服务挂了，如何解决
1.重试机制
2.限流
3.熔断机制
4.负载均衡
5.降级（本地缓存）
十.微服务需要考虑的问题
API网关（将所有API调用统一接入到API网关层，有网关层统一接入和输出）
服务间调用（异步和同步）
服务发现（zookeeper, Netflix Eureka )
服务容错(降级，限流，熔断器，超时重试)
服务部署
数据调用
from: https://www.nginx.com/blog/introduction-to-microservices/