读《微服务从设计到部署》笔记

1.每一个微服务都是自 包含（self-contained），各自维护本身的数据存储，这样就必须在设计数据库的时候考虑服务的相对独立性。

2.更容易差别化部署，好比有些服务对硬件要求低，有些就很高，能够差别化购买或搭建云服务。

3.符合DevOps 文化，什么是DevOps：http://www.javashuo.com/article/p-tsinxekl-dq.html

4.API网关，提供了统一的微服务单入口，提供负载均衡、缓存、访问控制、API 计量和监控。

5.微服务架构中的进程间通讯，微服务之间的相互通讯。

6.微服务架构中的服务发现，当服务运行在一个动态环境中，想要找到他们并非一件简单的事情，个人理解是由于环境是动态的，因此用注册发现机制能够实现相对稳定的访问机制。不该该由于微服务换了IP或者是主机而改变其余服务调用该微服务的方式。

7.微服务事件驱动数据管理：因为每一个微服务维护一个数据存储，致使应用变得复杂。因此引入了这个概念。

8.选择微服务部署策略

9.微服务架构模式明显影响到了应用程序与数据库之间的关系，与其余共享单个数据库 模式（schema）服务有所不一样，其每个服务都有本身的数据库模式

微服务最佳实践：

1.一个微服务尽量的解决一个问题。

微服务的缺点：

1.分布式系统确定比单系统复杂。

2.分区数据库架构，使得数据之间也相对独立，业务难于处理。

3.测试微服务也相对难。

4.另外一个主要挑战是实现了跨越多服务变动，依赖影响太复杂。

5.部署微服务也相对单服务复杂。

 

API网关相关：

1.客户端和微服务直接通信？？？？  直接通信是否就不能用负载均衡和集群了？？

2.API 网关负责请求路由、组合和协议转换，API 网关一般会经过调用多个微服务和聚合结果来处 理一个请求。它能够在 Web 协议（如 HTTP 和 WebSocket）和用于内部的非 Web 友 好协议之间进行转换。

3.API 网关须要支持各类 通讯机制。有时候不仅是http通信

进程间通信：

1.定义API，不管您选择何种 IPC 机制，使用接口定义语 言（interface definition language，IDL）来严格定义服务 API 都是很是有必要的。 有论据证实使用 API 优先法定义服务更加合理。

2.API定义的新旧版本问题，如何作到各类服务的升级协调一致性。解决方案：若是您使用了基于 HTTP 的机制（如 REST），则一种方法是将版本号嵌入 URL 中。。每一个服务实例可能同时处理多个版本。或 者，您能够部署多个不一样的实例，每一个实例用于处理特定版本。

3.处理局部故障：

断路器：追踪成功和失败请求的数量。若是错误率超过配置阈值，则断开断路器，以便后 续的尝试能当即失败。若是出现大量请求失败，则代表服务不可用，发送请求将 是无心义的。发生超时后，客户端应从新尝试，若是成功，则关闭断路器。

 

4,异步、基于消息的通讯：

a）点对点通道发送一条消息给一个切确的、正在从通道读取消息的消费者。服务使 用点对点通道，就是上述的一对一交互方式。

b）发布订阅通道将每条消息传递给全部已订阅的消费者。服务使用发布订阅通道， 就是上述的一对多交互方式。

c）基于消息的 IPC（进程间通讯）的优势：将客户端与服务分离 客户端经过向相应的通道发送一条消息来简单地发出一个请求。服务实例对客户 端而言是透明的。客户端不须要使用发现机制来肯定服务实例的位置。  消息缓冲 使用如 HTTP 的同步请求/响应协议，客户端和服务在交换期间必须可用。相比之 下，消息代理会将消息写入通道入队，直到消费者处理它们。这意味着，例如， 即便订单执行系统出现缓慢或不可用的状况，在线商店仍是能够接受客户的订单。 订单消息只须要简单地排队。

d）同步的请求/响应 IPC，如Swagger，容许您定义请求和响应消息的格式。

e）微服务必须使用进程间通讯机制进行通讯。在设计服务如何进行通讯时，您须要考虑 各类问题：服务如何交互、如何为每一个服务指定 API、如何演变 API 以及如何处理局 部故障。微服务可使用两种 IPC 机制：异步消息传递和同步请求/响应。为了进行 通讯，一个服务必须可以找到另外一个服务

 

5.服务发现机制