初识为服务
什么是微服务
使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里。一般采用轻量级的通讯机制互联，并且他们可以通过自动化的方式部署。
微服务特征
单一职责(只把紧密相关的业务放在一起，无关的业务独立出来，比如订单和支付作为一个服务，登录注册作为一个服务，和其他服务不紧密的比如邮件服务，短信服务可以作为一个服务)
轻量级的通信：微服务之间的访问和通信 (平台无关和语言无关，http就是轻量级的通信协议)
隔离线：每个微服务运行在自己的进程中
有自己的数据：微服务倾向都有自己的数据存储系统，这样可以降低数据结构的复杂度
技术多样性：微服务可以由开发人员选择最适合的技术，只要提供应有的API就可以了
微服务诞生背景
- 互联网行业的快速发展
- 敏捷开发，精益方法深入人心(说白了就是频繁的修改测试上线）
- 容器技术的成熟
微服务的优势
独立性:微服务从构建，部署，扩容，缩容，容错，数据库都是单独管理的，所以每个服务之间都是相互独立的
敏捷性：对使用者来说，微服务暴露的接口相对简单，因为功能单一，并且有清晰的api,当有新需求时，也可以快速定位到是在哪个微服务中开发
技术栈灵活：理论上每个微服务都可以有自己独立的技术栈，不会受到其他微服务的影响
高效团队：微服务开发的人员不多，可以几个人开个小会就把需求定下来
微服务的不足
额外的工作：服务的拆分，要把我们的服务拆解成微服务。tdd领域驱动设计
数据一致性：单体架构只有一个数据库，可以使用事务来实现多表的级联的修改和删除很容易达到数据的一致性，微服务都有自己的数据库，拆分微服务的时候要尽量保证对数据库的连表操作，尽量在同一个微服务里面。但是很难保证意外的情况
沟通成本：微服务的api的改变带来的沟通成本，因为可能需要改变的地方并不仅仅只是自己的服务，还涉及到其他服务，则这个时候推动项目的前进的沟通成本很高
微服务架构引入的问题和解决方案
微服务间如何通信？
从通讯模式角度考虑
- 一对一还是一对多？
同步还是异步？
| 一对一 | 一对多 | |
|---|---|---|
| 同步 | 请求响应模式，最常见 | ———–（没有这样的场景） |
| 异步 | 通知(不需要响应)/请求异步响应(不需要立即响应) | 发布订阅/发布异步响应 |
从通讯协议角度考虑
REST API
1 | RPC : dubbo ,grpc, thrift, motan |
MQ : 消息队列，发布订阅的模式
如何选择RPC框架
I/O,线程调度模型:
是同步的IO还是非阻塞的异步IO。是长连接还是短连接。 )
是单线程还是多线程，线程的调度算法是怎么样的
序列化的方式——->通信的效率
可读的
二进制
多语言支持：是否都是一个语言开发
服务治理：服务发现和服务的监控
服务发现、部署、更新
不管微服务还是传统服务，绝大多数对外提供访问的方式是ip+port的方式.
传统服务的 “服务发现”
client—>dns服务器—>nginx轮训对应的ip和端口—->服务器
这也不算是服务发现，每次新增服务的时候，需要重新配置。
微服务的服务发现
- 客户端的发现
最下面有一个注册中心，当微服务启动之后，都会把自己所暴露的ip和port告诉给注册中心，然后客户端通过查询注册中心所注册的服务来得知微服务提供者的ip和port列表，然后通过本地的一些负载均衡等策略来实现对微服务的无差别访问，如果出现一些调用失败的情况，客户端也有自己的重试的规则。
dubbo和motan就是这种模式
服务端的发现
微服务还是同样的将自己的ip和port注册到注册中心，但是客户端不访问注册中心了，他不需通过注册中心指导微服务的列表，而是通过一个固有的ip去访问一个具有服务发现和负载均衡的服务，再由他将请求转发给后端的具体服务，并且将应答返回给客户端，这个服务在中间起到一个类似代理人的作用，他会从注册中心获取到具体的微服务列表，然后维护到自己的内部，然后当客户端请求一个服务的时候，他会知道客户端应该请求的是这个服务对应的哪些实例在运行，然后通过负载均衡算法去选择一个后端。
服务编排
服务编排包括，服务发现，服务更新和服务的扩缩融
流行的服务编排工具：
Mesos Docker Swarm kubernetes