[聚合文章] 微服务设计-笔记

最近在做交易系统的重构, 整体学习了下 微服务的相关理念. 看了一本书, 微服务设计-豆瓣链接 .

作者相关信息: Sam Newman . 个人网站地址: sam newman ThoughtWorks技术专家.

以下是具体的笔记内容:

规模化微服务

故障无处不在

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . 分布式计算的谬论:

• 网络是可靠的.
• 延时为0
• 带宽是无限制的
• 网络是安全的
• 拓扑是不会变的
• 只有一个管理员
• 传输成本为0
• 网络是是均匀的.
  针对谬误, 软件设计和开发过程中, 需要做一些降级去处理这些问题, 拥抱这些故障.

系统指标

• 响应时间
• 可用性
• 数据持久性

功能降级

从业务角度来思考, 我们该如何对不同的系统优雅的降级使用.

架构性安全措施

有一些模式，组合起来被称为架构性安全措施，它们可以确保如果事情真的出错了，不会引起严重的 级联影响 .

如何来解决下游服务的不可用, 导致一个依赖服务拖垮我们整个服务, 耗尽对外的http线程池?

反脆弱性在netflix中的使用

反脆弱性在netflix上的使用

• Netflix通过引发故障来确保其系统的容错性
• 谷歌通过 DiRt. 灾难恢复测试来测试系统.

• Netflix chaos monkey. 随机停掉服务器. 制造混乱

  • Simian Army
  • Latency Monkey
  • chaos monkey

• 正确设置超时时间.

  • 设置默认超时时间, 防止超长时间等待.
• 实现仓壁隔离不同线程池
  • 实现不同业务的线程池隔离. 推荐 netflix的hystrix解决方案.
• 实现断路器
  • 当对下游资源的请求发生一定数量的失败后，断路器会打开
  • 断路器模式 断路器
• 隔离
  • 一个服务越依赖于另一个，另一个服务的健康将越能影响其正常工作的能力.

幂等

- 多次执行操作和一次执行操作幂等. 退款就应该是这样. 重复支付失败. 
- 如何进行隔离? 如何隔离?

负载均衡

• 是把所有的微服务实例都 放在一个独立的 VLAN 里。VLAN 是一个虚拟局域网，所有的外部请求只能通过一个路由 器访问内部。在这个例子中，这个路由器也就是 SSL 终端负载均衡器。VLAN 外部跟微服 务通信的唯一方式是通过 HTTPS，而内部的所有通信都是通过 HTTP. 内部的负载均衡. nginx只用来进行SSL加密通信.

重新设计

你的设计应该“考虑 10 倍容量的增长，但超过 100 倍容量时就要重写 了”。在某些时刻，你需要做一些相当激进的事情，以支持负载容量增加到下一个级别。 参考: Challenges in Building Large-Scale Information Retrieval Systems

扩展数据库

• 服务可用性 VS 数据持久性. 不同的概念.
• 扩展读取.
  • 读从库. 可能会有数据一致性问题. CAP原理
  • 读缓存.
• 扩展写
  • Hash -> 分片. mysql. 分库分表. 缓解压力
  • 问题. 如何进行跨分片的查询. 同步到NOSQL进行查询.
  • 内存计算.聚合返回 / 替代的读数据库包含所有数据. ES.
  • mongdb . cassandra. 替换的选择. NOSQL数据库.
• CQRS. (command-query responsibility segregation).
  • 将查询和修改状态的请求命令进行隔离.
  • CQRS的说明和解释 Martin Fowler: CQRS

使用缓存

• 客户端缓存

  • 可以减少客户端调用次数
  • 无法使全部消费者同时发生变化

• 服务端缓存

  • 一切对客户端都是不透明的，它们不需要关心任何事情。缓存在服务 器外围或服务器限界内时，很容易了解一些类似数据是否失效这样的事情，还可以跟踪 和优化缓存命中率.

• 代理服务器缓存

  • 不需要每次查询.

• HTTP缓存

  • cache-control. 控制是否需要缓存该时间.
  • expires头部, 失效时间.
  • Etag. 可以发送缓存内容的最新版本号.

• 为写试用缓存

  • 后写式缓存(writebehind) - 批量处理操作.
    • 如果你使用后写式(writebehind)缓存，可以先写入本地缓存中，并在之后的 某个时刻将缓存中的数据写入下游的、可能更规范化的数据源中
    • write-back
    • cache写机制

• 防止缓存突然全部失效

  保护源服务 - 后台重建缓存

• 保持简单

  缓存越多，就越难评估任何数据的新鲜程度

CAP原理

在分布式系统中有三方面需要彼 此权衡:一致性(consistency)、可用性(availability)和分区容忍性(partition tolerance)。 具体地说，这个定理告诉我们最多只能保证三个中的两个。

• 需要根据你的业务来具体判断, 你的系统需求属性. 比如: 我们的系统作为一个整体，不需要全部是 AP 或 CP 的.

服务发现

• 动态服务机制

  • zookeeper. 树形的结构, 可以增加新的节点. 复杂的选举机制,来确保可用性.Zookeeper 的核心是提供了一个用于存储信息的分层命名空间

  • Consul. Consul 提供的杀手级特性之一是，它实际上提供了现成的 DNS 服务器. 网址: http://www.consul.io/ . 项目github地址: https://github.com/hashicorp/consul

  • Eureka. netflix提供的服务发现功能.Netflix 的开源系统 Eureka( https://github.com/Netflix/eureka )

文档服务

API文档服务解决方案: Swagger. 用动态的接口来展示文档.

总结

坚持反脆弱性信条

心中持有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确 的路上.

• 设置 超时
• 使用 仓壁和断路器

实现微服务体系化

• 围绕业务概念建模
• 接收自动化文化
  • 接受自动化测试工作
• 隐藏内部实现细节
  • 隐藏数据库
• 一切都去中心化
• 可独立部署
  • 蓝绿部署. 灰度部署, 经历一个完整的高峰期.
  • 金丝雀部署技术. 区分部署和发布.
• 隔离失败
  • 断路器
  • 仓壁模式
• 高度可观察
  • 通过语义监控
  • 聚合日志和数据