测试
- 优化快速反馈，并相应地使用不同类型的测试
- 尽可能使用消费者驱动的契约测试来替换端到端测试
- 使用消费者驱动的契约测试，提供团队之间的对话要点
- 尝试理解投入更多的努力测试与更快地在生产环境发现问题之间的权衡
在《敏捷软件测试》中，提出了对于不同测试类型分类的测试象限，其中单元测试、非功能测试是面向技术开发人员的。
这一章节将测试按照金字塔结构分成三层，从上往下依次为用户界面测试、服务测试、单元测试，越往下应该测试得更快以及隔离性更好，一个好的法则是下面一层的测试数量比上面一层多一个数量级。
一个服务测试用来测试其中一个单独服务的功能，为了达到隔离功能，需要外部合作者配合打桩
打桩是指为待测试的服务创建一些有着预设响应的服务
与打桩相比mock还会进一步校验请求本身是否被正确调用
在团队中如何维护这些测试套件，文中的观点是，共享端到端测试套件的代码权，但同时对测试套件联合负责。团队可以随意提交测试到这个但是实现服务的团队需要负责维护这些提交是否正确。
CDC，消费者驱动契约，定义服务的消费者期望，这些最终会变成对生产者运行的测试代码。并且CDC同样作为生产者部署是的单元测试一部分，保证这个期望不会被破坏以及消费端不会产生异常
上线后的测试也同样重要，例如通过蓝绿部署或者金丝雀部署(一点点调大流量到新版本)，保证如果错误，能够迅速切回到旧版本
平均修复时间有时比平均故障间隔时间更有意义，减少修复时间即尽快回滚加上良好的监控
监控
对于服务来说
- 请求响应时间，以及更高要求的指标，例如跟踪错误率
- 下游服务的健康状态、响应时间等
- 标准化如何收集以及存储指标
对于系统而言
- CPU、网络、磁盘等系统级的指标
- 考虑如何存储以及满足足够长时间的数据
一个观点，不要忽略任何信息，尽快捕获并存储，搭建好监控平台，比真正出现问题确无从排查更好
安全
一旦你了解系统不同部分的威胁级别，就可以知道什么时候需要考虑传输中的安全，什么时候需要考虑静态安全，或根本不需要考虑
SSO单点登录，访问资源时给定位到身份提供者那里验证省份，确认成功拿到票据，之后通过票据就能够访问资源
细粒度的授权
https
不要自己发明加密算法
康威定理
任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致
康威定理强调了试图让系统设计跟组织结构不匹配所导致的危险
规模化微服务
规模化后，故障将成为必然事件
弄清楚每个故障的影响，并弄清楚如何恰当地降级功能
处理系统缓慢比处理系统快速失败困难的多，所以为了避免这种情况，正确的设置超时，实现舱壁隔离不同的连接池，并实现断路器，以便在第一时间避免给一个不健康的系统发送调用
混沌测试，模拟故障发生，演练如何应对这种情况
如果操作是幂等的，可以重复多次调用，而不必担心有什么不利影响。通过添加更多信息来标识是同一个请求
对worker、数据库等进行扩展，负载均衡，加大处理能力
CAP定理: 一致性、可用性、分区容忍性，最多只能保证其中的两个。
- 最终一致的AP系统
- 很难实现和扩展的CP系统
- 不存在CA，因为容忍分区，就代表着不能跨网络运行，即在本地运行一个单独的进程，在分布式系统是不存在的。
服务注册与发现: 高度动态的环境发现节点的方法，包括服务注册和一些集中的注册表
文档服务: 描述一个服务有什么用处，确保文档总是和最新的微服务API同步，swagger、hal
hal可以在任何给定的接口上查看有哪些功能，同时健康检查页面和单个服务的健康状态
总结
微服务，自治的小服务，原则
1、围绕业务概念建模 2、自动化的文化 3、隐藏内部的实现细节 4、一切都去中心化 5、独立部署 6、隔离失败 7、高度可观察