第一章 微服务
1.定义
就是一堆协同工作并且小而自治的服务。 小(足够小，但不是越小越好)就是订单，商品，购物车，下单，用户，权限等等都抽出来，分别做成单独个服务，每个服务只负责自己的事。相对应的，每个服务，都可以独立部署，服务间使用网络通信，彼此可以独立修改，不会因为某一个服务部署，影响该服务消费者的变动。
2.好处
2.1 技术异构性，微服务的节点服务，可以根据需求使用不同的技术组合。例如论坛， 数据库可以采用 mysql存储用户信息，mongodb存储帖子信息(大量文字)，oss存储图片等等.对新技术的使用友好,每次可以选择最小的一个服务,来使用新的，不同的技术。
2.2 弹性，扩展，简化部署：Consul 心跳检测和服务器升降级，例如下单时，服务器不够了，直接加个服务器就行了，只部署下单服务即可(单个服务器，需要把整个网站部署一遍)。
2.3 重用,组合：对于web,移动端，一套api，都可以使用。
第二章 演进式架构
1. 架构师职责:确保团队拥有共同的愿景，以帮助我们向客户交付他们想要的系统。架构师对多个方面都有很深的影响：构建系统的质量，工作条件等等。不要设计一个完美的架构，要根据需求设计一个可以演进式的架构，应对日益变化的客户需求和市场。
2. 分区：应该关注服务间的交互，而不是单个服务。每个服务，都是由单独的团队负责，采用自己的技术，但是一定要在把控之内，避免太多的技术，否则招聘时找不到人。(要参与进项目代码中，与团队一起工作)
3. 监控：使用同一个方式做每个服务的监控，接口也是如此，同一种风格的接口。
4. 架构安全性: 不能因为一个服务错误，整个网站都崩溃，每个服务都能应对下游的错误请求，同时也可以方便追溯问题。例如：1.正常并且正确处理的请求 2.错误请求，但是什么都不做 3.服务宕机
5. 写demo和api文档
6. 技术债务:有时为了紧急任务(需求变更)，而忽略的一些约束。短期有利，长期可能带来损失，所以要做取舍权衡。
7. 集中治理,领导, 建设团队,帮助团队成长,让他在负责当前服务的情况下，给他们更多的责任，也放置某一个人责任过重。
第三章 建模
1. 微服务核心就是高内聚低耦合。想要建模，就要找到业务之间的上下文。先识别一些粗粒度的上下文，再根据具体业务，拆分细粒度的上下文进行建模。
2. 技术边界，选定各个api之间使用的通信技术。
第四章 集成
1. 避免破坏性更改：例如增加了一个字段，消费方不受影响
2. 保证api的技术无关性：例如现在用.net,5年以后可能用java，python等等.
3. 使你的服务易于消费方使用，但是会增加耦合，所以要隐藏内部实现细节
4. 为用户创建接口，避免使用数据库集成，如果多个服务都要修改用户信息，数据库集成会很麻烦
5. 同步与异步，编排与协同
6. 远程调用: RPC，REST,HTTP, 与本地调用不一样,会有各种各样的问题，性能，复杂性，网络通信时间，断网等等，网络是脆弱的。一般都是用json解析。
7. 实现基于事件的异步协作机制：主要有两个部分需要考虑：微服务发布事件机制和消费方接受事件机制。例如RabbitMQ
8. 响应式扩展，DRY(Don’t Repeat Try),代码重用，版本管理，及早发现破坏性修改
9. 不同的接口共存(蓝绿部署)，同一个服务，可以使用新旧两种接口。将旧接口的用户，逐步引导到新接口。
10 用户界面UI,与第三方软件集成
第五章 分解单块系统
1. 先分解业务,识别边界，然后慢慢拆分成多个单个服务.对业务影响小，也方便追踪。识别出边界后，先分离数据库，再分离代码。
2. 分布式事务，报告数据库（独立服务拉取数据形成报告或者独立程序直接访问数据库并导出成报告）或者在实体修改时添加事件将数据导入到报告数据库中
第六章 部署
1. CI(持续集成)：能保证新老代码集成，并且所有人一致,并验证代码是否编译通过和测试通过。通过CI，能快速得到代码质量的某种程度的反馈，并且测试可视化。理解CI三个问题：
1.1 是否每天都嵌入代码到主线
1.2 是否有一组测试来验证修改
1.3 构建失败后，团队是否把修复CI当成第一级的事件来处理
2. 把CI映射到微服务：
3. 构建流水线和持续交付: 把构建分成多个阶段很有价值，第一阶段快速测试，第二阶段耗时测试，如果其中一个耗时特别长，另外一个耗时短的报错了，只能等待全部执行完毕后，才能返回错误。
CD(持续交付,就是基于上面的概念)能够检测每次提交是否达到了部署到生产环境的要求并反馈。
第七章 自动化测试
1. 单元测试:
2. 服务测试：测试单个服务
3. 端到端测试：浏览器测试等等
4. 测试所占比例：单元测试>服务测试>端到端测试
5. 跨功能测试： 能接受的网络延时时间是多少，支持的用户量，如何保障数据安全等等
6. 性能测试：
第八章 监控
1. 监控小的服务，聚合起来看整体
2. 多个服务，多个服务器时，从日志到应用程序指标，集中收集和聚合尽可能多的
数据到我们手上。
3. 日志：logstash:解析多种日志并发给下游；Kibana:基础ElasticSearch的查看日志的系统。
4. 关联标识：触发第一个调用时，生成一个GUID,然后把这个GUID传递给所有的后续调用。
5. 考虑受众，是给老板看，还是给运维看，有3个要素：他们现在要什么，他们之后想要什么，如何消费数据
第九章 安全
1. 身份验证和授权
1.1 单点登录SSO
2. 服务间认证和授权：使用HTTPS，API秘钥
3. 静态数据安全： 使用众所周知的加密算法，不要试图自己写。
4. 深度防御：防火墙，日志，入侵检测系统IDS, 入侵预防系统IDS,网络隔离(将微服务的各个服务，放进不同的网段)
5. 服务器的操作系统及时打补丁
6. 人的因素:例如离职员工登录服务器搞破坏
7. 内建安全:用工具自检；外部验证：渗透测试
第十章 规模化微服务
1. 故障无所不在
1.1 响应时间/延迟
1.2 可用性， 系统是不是7/24可用，
1.3 数据持久性 普通日志定期删除，财务日志保管很多年
2. 功能降级，弹性扩展，虚拟化，负载均衡: Consul,真有错误，给个友好的提示。
3. 重新设计系统，扩展数据库，CQRS(命令查询职责分离，系统一部分只管增删改，另一部分只管查询)
4. 缓存：客户端缓存(cookie,HTTP缓存【cache-control，expires,Etag】)，代理缓存(CDN或者nginx)，服务端缓存(redis等等),写缓存(先写入缓存，在某个时刻持久化到数据库中，例如聊天，秒杀等场景)，同时避免使用多层级的缓存，缓存太多，更新时数据会出错。就是俗称的缓存中毒。
5. 自动伸缩
6. CAP：C(一致性) A(可用性) P(分区容错性) ，在分布式中，最多只能满足2个条件，需要根据业务做出取舍和权衡。
7. 文档服务：Swagger
