微服务设计笔记

微服务思想能否在计算机服务中实现蜂群效应？

单主机部署多个服务的弊端

1. 监控困难。监控整个主机还是具体到某一个服务？
2. 资源占用。每个服务之间计算资源的占用是不可控制，相互影响的。
3. 依赖冲突。每个服务依赖可能不同，甚至冲突。
4. 不利于服务团队自治。该主机该由哪个团队进行维护？
5. 强行统一不同服务的运行环境。每个服务所需要的运行环境可能有所偏好，比如有的计算密集，有的涉及存储。而单个主机的部署导致所有服务都只能妥协于同一个运行环境。

微服务测试

1. 端到端的测试是脆弱的。测试涉及众多其它相关服务，这些服务可能会出现错误，导致测试无法达到测试想要的服务的目的。
2. 遇到脆弱的测试应该及时修复问题，而不是接受这种异常，认为是出错是理所当然的。
3. 端到端的测试应该尽快完成，否则开发人员已经开始干新的事情，切换大脑的上下文来修复测试是很痛苦的。
4. 端到端的测试，把注意力放到测试场景上，而不是测试故事上，测试重心放到核心的测试场景上面。

身份验证和授权

SSO(Single Sign-On,单点登录)指，当主体试图访问一个资源时，会首先被定位到一个身份提供者那里进行身份认证。主体通过验证以后，身份提供者向服务提供者发送消息，让服务提供者决定是否允许他访问资源。

黄金法则：不要实现自己的加密算法，不要发明自己的安全协议。

如何应对微服务系统故障

在错误发生时采用不指责文化。

事物受益于失败和混乱。

超时处理。在调用下游服务时，应该设置一个默认的超时，并且根据日志调整超时参数。

断路器。使用断路器时，当对下游资源的请求发生一定数量的失败后，断路器会打开。接下来，所有的请求在断路器打开的状态下，会快速地失败。一段时间后，客户端发送一些请求查看下游服务是否已经恢复，如果它得到了正的响应，将重置断路器。

舱壁。把自己从故障中隔离出来的一种方式。

幂等

对于幂等操作来说，其多次执行产生的影响，均等于一次执行的影响。当不确定一个操作是否被执行，想要重新处理消息，从而从错误中恢复时，幂等会很有用。

CAP定理

分布式系统需要在三方面进行权衡：一致性（consistency），可用性（availability）和分区容忍性（partition tolerance）。定理表明，最多只能保证三个中的两个。

AP: 系统无法保证一致，比如服务节点之间无法同步数据。弥补方法可以采用最终一致性，在将来的某个时刻，所有的节点都能看到更新后的数据，但是不会立即发生，用户可能看到失效的数据。

CP：为了保证数据一致，该服务先暂时停用，这时要做好功能降级。保证一致性是困难的，不要试图自己实现一个一致性数据存储。

在分布式系统中，CA是不存在的。