《微服务设计》8、10章笔记
上一篇 《微服务设计》6、7章
第八章 监控
多服务如何监控？
8.1 单一服务，单一服务器
指标：
- cpu
- 内存
- 响应时间
- 错误次数
工具： Nagios ， New Relic
8.2 单一服务，多个服务器
- 多实例，负载。
- 负载也要做监控
8.3 多服务，多服务器
- 如何确定是哪一个服务器异常，还是系统性异常？
- 错误链路如何跟踪
- 日志(查找+分析)
- ELK
- elasticSearch
- logstash
- kibana
8.5 多个服务的指标跟踪
足够长时间指标数据，直到有清晰的模式浮现。
**工具：Graphite **
- 可以跨样本聚合
- 减少到30分钟做聚合（减少存储）
8.6 服务指标
- 公开自己服务的基本指标。（最基本的也要有 错误率+响应时间）
- 只要哪些功能是常用的与极少使用的。
比如：
- 发布了新功能，使用情况如何？
- 只有直到很久以后，你才会知道什么数据最为有用。
工具:metric库
- 计数器
- 计时器
- 时间限制的指标
8.7 综合监控
系统是否正常工作？（系统越来越复杂之后，很难分析）
做法：
. Nagios插入一个假事件，当系统响应到这个事件时候执行真实的操作，
只是返回的结果是用于测试。
语义监控
- 测试用例？与线上测试用例？
- 准备好，能测试的数据。（配置假用户+与相关数据）
8.8 关联标识
- 复杂的请求怎么找到对应上下游链路呢？
- 其中还有异步的请求怎么办？
- 问题如何重现呢？
目标：
- 结构化数据，日志聚合工具
- 制定强行的标准。
- 工具：
- Zipkin
- ID （可以做在http头）
- 直到问题出现才需要它。但只有在开始就存在才能标记错误。
8.9 级联
- 监控系统之间如何集成？
- 一个服务无法访问另外一个服务的时候就应该告警了吧？
工具:Hystrix
8.10 标准化
不同服务+不同合作方式，如何全视角看系统呢？
8.11 考虑受众
- 他们现在需要知道什么？
- 之后需要什么？
- 如何消费数据
统一收集，聚合+存储（Kibana）
第十章 康氏定律和系统设计
我们的行业还很年轻，它似乎在不断地重塑自己。
摩尔定律
集成电路上可容纳的晶体管数目，每两年会增加一倍。
- 任何组织在设计一套系统（广义概念上的系统）时，
- 所交付的设计方案在结构上都与该组织的沟通结构保持一致。
10.1 证据
- 松耦合组织和紧耦合组织
- 小团队比大团队高效
- 有更改重构，讨论很容易
- 很有责任感
粗粒度的沟通
最终匹配符合沟通的粗粒度api
服务所有权
- 更改
- 需求构建部署，运维
- 激励团队去部署自己的服务
共享服务
- 服务太大需要拆分
- 特性团队（给予特性开发，可能跨越服务组件的边界）
- 交付需求太多（增添临时支援）
内部开源
- 核心团队，团队以外的人
- 需要审核。
- 好的审核者会与提交者清晰地沟通，
- 坏的审核者只会发号施令。
服务不成熟就很难给团队以外的人提交。
- 服务边界与交互
- 孤儿服务（不再活跃和维护）
每个业务线团队负责自己创建的服务的整个生命周期
- 行为和管理上有很大的自由
- 可随时停止服务，可以批量集成
- 自己业务干系人的需求。
反向的康威定律
系统设计能改变组织？
人
- 不管一开始看起来怎么样，它永远是人的问题。
- 人系统的拥有者，系统未来也在人的手上。
- 现在的你有什么感受，做事情的时候又有什么设想呢？
