此篇是早前《微服务设计》的读书笔记，在此记录一下。
微服务
微服务就是一些协同工作的小而自治的服务。
- 每个服务都很小，专注于做好一件事。
- 服务之间均通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。
微服务的好处
- 技术异构性
- 弹性
- 扩展
- 简化部署
- 与组织结构相匹配
- 可组合性
- 对可替代性的优化
没有银弹！ 为了得到微服务的好处，需要在部署、测试和监控方面做很多的工作，还需要考虑如何扩展系统，并且保证它们的弹性，也还需要处理分布式事务或者与CAP相关的问题。
很多组织采用微服务是为了使团队的自治性最大化。
演进式架构师
- 愿景、同理心、合作
- 保证该系统适合开发人员在其上工作
- 从更高的层次出发，理解如何做权衡
- 治理和监督
如何建模服务
好服务的标准
- 高内聚
- 低耦合
集成
微服务之间通信方式的选择非常多样化
- SOAP
- XML-RPC
- REST
- Protocol Buffers
- Thrift
本地调用和远程调用并不相同
- RPC的核心想法是隐藏远程调用的复杂性。使用本地调用不会引起性能问题，但是RPC会花大量的时间对负荷进行封装和解封装，更别提网络通信所需要的时间。
- 需要注意的是，HTTP也可以用来实现RPC。比如SOAP就是基于HTTP进行路由的，但不幸的是它只用到HTTP很少的特性，而动词和HTTP的错误码都被忽略了。
- 通过HTTP我们可以发送任何格式，甚至是二进制的。
实现基于事件的异步协作方式
服务即状态机
使用语义化的版本管理
- MAJOR.MINOR.PATCH
- 短期内同时使用两个版本的服务是合理的，尤其是当你做蓝绿部署或者金丝雀发布时
API组合
使用API入口（gateway）可以缓解移动设备与服务过多通信的问题，在这种模式下多个底层的调用会被聚合成为一个调用，当然它也有一定的局限性。
分解单块系统
- 最好考虑把哪部分代码抽取出去得到的收益最大，而不是为了抽取而抽取
- 想要抽取出来的接口应该尽量少的被其它组件所依赖
- 先分离数据库，再对服务进行分离
- 重试保证最终一致性
- 补偿事务
- 分布式事务，事务管理器
部署
真正理解CI的三个问题
- 每天签入代码到主干
- 有一组测试来验证修改
- 把修复CI当做第一优先级的事情来做
平台即服务
PaaS（Platform-as-a-Service）
传统的虚拟化技术
采用标准虚拟化的如AWS、VMWare、VSphere、Xen和KVM等。
基于轻量级容器的虚拟化（LXC）
Docker
测试
单元测试
TDD：Test-Driven Development，测试驱动开发
Mock还是打桩
金丝雀发布
- 金丝雀发布是指通过将部分生产流量引流到新部署的系统，来验证系统是否按预期执行。
- 金丝雀发布与蓝/绿发布的不同之处在于，新旧版本共存的时间更长，而且经常会调整流量。
- Netflix广泛采用金丝雀发布的方式，通过对比新版本与基线版本的分数，只有当新版本分数更高时，才会全面部署新版本到生产环境。
平均修复时间胜过平均故障间隔时间
- 平均故障间隔时间（MTBF，Mean Time Between Failures）
- 平均修复时间（MTTR，Mean Time To Repaire）
监控
监控小的服务，然后聚合起来看整体。
安全
- 单点登录SSO（Single Sign-On）
- HTTPS基本身份验证
- 客户端证书TLS（Transport Layer Security，安全传输层协议）
- API秘钥
不要实现自己的加密算法，不要发明自己的安全协议。
康威定律与系统设计
- 组织和架构应该一致，信奉这个理念的两个典范是Amazon和Netflix。
- 每条业务线团队，负责自己创建的服务的整个生命周期，包括构建、测试、发布和运维，甚至弃用。
规模化微服务
当微服务的数量比人还多时，有什么应对的模式吗？
- 故障无处不在
除了使用流程和控制来试图阻止故障的发生外，更应该思考如何更加容易的在第一时间从故障中恢复过来。 - 功能降级
- 年度DiRT（Disaster Recovery Test，灾难恢复测试）
- 超时、断路器
- 幂等
- CQRS（Command-Query Responsibility Segregation，命令查询职责分离）模式，是一个存储和查询信息的替代模型。
缓存
- 客户端、代理和服务器端缓存
- HTTP缓存：
- cache-control
- expires
- etag（entity tags）
CAP定理
在分布式系统中，需要有三方面进行权衡：
- 一致性（consistency）
- 可用性（availability）
- 分区容忍性（partition tolerance）
如果系统没有分区容忍性，就不能跨网络运行。换句话说，需要在本地运行一个单独的进程。所以，CA系统在分布式系统中根本是不存在的。选择AP还是CP，在现实中要视情况而定。
服务发现
动态服务注册
- Zookeeper
- Consul
总结
- 围绕业务概念建模
- 接受自动化文化
- 隐藏内部实现细节
