《微服务设计》8、10章笔记

上一篇 《微服务设计》6、7章

第八章 监控

多服务如何监控？

8.1 单一服务，单一服务器

指标：

• cpu
• 内存
• 响应时间
• 错误次数

工具： Nagios ， New Relic

8.2 单一服务，多个服务器

• 多实例，负载。
• 负载也要做监控

8.3 多服务，多服务器

• 如何确定是哪一个服务器异常，还是系统性异常？
• 错误链路如何跟踪
• 日志(查找+分析)
• ELK
  • elasticSearch
  • logstash
  • kibana

8.5 多个服务的指标跟踪

足够长时间指标数据，直到有清晰的模式浮现。

**工具：Graphite **

• 可以跨样本聚合
• 减少到30分钟做聚合（减少存储）

8.6 服务指标

1. 公开自己服务的基本指标。（最基本的也要有 错误率+响应时间）
2. 只要哪些功能是常用的与极少使用的。

比如：

• 发布了新功能，使用情况如何？
• 只有直到很久以后，你才会知道什么数据最为有用。

工具:metric库

1. 计数器
2. 计时器
3. 时间限制的指标

8.7 综合监控

系统是否正常工作？（系统越来越复杂之后，很难分析）

做法：
. Nagios插入一个假事件，当系统响应到这个事件时候执行真实的操作，
只是返回的结果是用于测试。

语义监控

• 测试用例？与线上测试用例？
• 准备好，能测试的数据。（配置假用户+与相关数据）

8.8 关联标识

• 复杂的请求怎么找到对应上下游链路呢？
• 其中还有异步的请求怎么办？
• 问题如何重现呢？

目标：

• 结构化数据，日志聚合工具
• 制定强行的标准。
• 工具：
  • Zipkin
  • ID （可以做在http头）
  • 直到问题出现才需要它。但只有在开始就存在才能标记错误。

8.9 级联

• 监控系统之间如何集成？
• 一个服务无法访问另外一个服务的时候就应该告警了吧？

工具:Hystrix

8.10 标准化

不同服务+不同合作方式，如何全视角看系统呢？

8.11 考虑受众

• 他们现在需要知道什么？
• 之后需要什么？
• 如何消费数据

统一收集，聚合+存储（Kibana）

第十章 康氏定律和系统设计

我们的行业还很年轻，它似乎在不断地重塑自己。

摩尔定律

集成电路上可容纳的晶体管数目，每两年会增加一倍。

• 任何组织在设计一套系统（广义概念上的系统）时，
• 所交付的设计方案在结构上都与该组织的沟通结构保持一致。

10.1 证据

• 松耦合组织和紧耦合组织
• 小团队比大团队高效
  • 有更改重构，讨论很容易
  • 很有责任感

粗粒度的沟通

最终匹配符合沟通的粗粒度api

服务所有权

• 更改
• 需求构建部署，运维
• 激励团队去部署自己的服务

共享服务

• 服务太大需要拆分
• 特性团队（给予特性开发，可能跨越服务组件的边界）
• 交付需求太多（增添临时支援）

内部开源

• 核心团队，团队以外的人
• 需要审核。
  • 好的审核者会与提交者清晰地沟通，
  • 坏的审核者只会发号施令。

服务不成熟就很难给团队以外的人提交。

1. 服务边界与交互
2. 孤儿服务（不再活跃和维护）

每个业务线团队负责自己创建的服务的整个生命周期

1. 行为和管理上有很大的自由
2. 可随时停止服务，可以批量集成
3. 自己业务干系人的需求。

反向的康威定律

系统设计能改变组织？

人

1. 不管一开始看起来怎么样，它永远是人的问题。
2. 人系统的拥有者，系统未来也在人的手上。
3. 现在的你有什么感受，做事情的时候又有什么设想呢？