最近对服务端架构非常感兴趣，刚好 YouTube 给我推了这则视频 https://www.youtube.com/watch?v=CZ3wIuvmHeM 简直是想睡觉有人递过来枕头，看完有不少收获，在此记录一二。
Microservices
2000 年的 Netflix DVD 数据中心架构如下：
图中的 Monolithic 即“巨石型”，可以脑补一下 macOS 某个版本中的酋长岩桌面，非常宏大的单体的意思。2000 年的 Netflix DVD 数据中心用的单一代码库和数据库，架构耦合非常重。服务本身的架构非常常见，入口做负载均衡，背后是一大堆 Linux 服务器，架构看起来是 J2EE。
然后就是逐渐开始往 microservice 架构去切，引用的一些理论表述：
…the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. — Martin Fowler
好处主要是 Separation of conerns（熟悉 HTML+CSS+JavaScript 的前端应该不会对此感到陌生）、可伸缩性、以及虚拟化和弹性。Netflix 的中台设计（Middle Tier & Platform）：
直译过来大致有：
- 产品中台：
- A/B 测试
- 订阅服务
- 推荐系统
- 基础平台
- 路由
- 配置
- 加解密
- 持久化
- 缓存
- 数据库
FIT
服务拆解本身并不难，各个微服务稳定、网络通畅的时候，通常看上去都很美。但是假如遇上微服务单点不稳定、网络拥塞、调用失败，存在业务逻辑错误或者伸缩不成功，这些情况都很容易让美好的架构破功。Netflix 引入了一套微服务调用设计模式：
为了验证相关设计实现的有效性，Netflix 还专门做了一个验证工具叫做 FIT（Fault Injection Testing）专门用来搞破坏，可以按设备或者用户干预，也可以按 % 切流量，切到 100% 就可以验证某个微服务完全不可用的情况。
还有个有趣的观点是关于客户端的，一般为了更好地应对分散的服务调用，会通过搭建一个 rpc hub 加上配套的调用客户端来聚合这些 api，在阿里最常见的莫过于 HSF（以及它的开源版本 Dubbo）。但 Josh Evans 分享了一个完全相反的观点，认为这样的设计是一种 slippery of slope，最终导致给微服务架构引入了一个新的超大单体，并建议在实际应用中要忍住这样的诱惑，宁愿互相直接调用，冗余一部分调用逻辑并不是大问题。
Netflix 多年前也经历了一次类似支付宝网线被挖断的事情，2012 年的平安夜 Netflix 依赖的亚马逊云服务 US-East-1 彻底挂掉：
从这件事情上得到的最大教训是，不应该将所有的鸡蛋放在一个篮子里面。因为如果全放到一起，出了问题完全没有办法找到备份。所以在这之后 Netflix 做了不少冗余设计，比如 EVCache 有多可用分区，将缓存数据按照设备或者用户 id 氛围多个区域，EVCache 的写入逻辑是多区写入，不仅写入当前可用分区的多个节点，还会写到其他可用分区中，读取逻辑则优先当前分区保证效率，但如果读取失败，其他分区就可以派上用场。
Solutions First
Josh Evans 在演讲末尾分享的 Conway’s Law 也非常有趣，这条法则知名度不低，在演讲中提到的背景是：
Josh: what is the right long term architecture? Peter: do you care about the organizational implications?
Peter 提到的 organizational implications 即 Conway’s Law，举一些例子比如，如果你有四个团队在维护一个编译器，最后你就会得到一个 four pass compiler（不太确定 pass 如何翻译，含义可以简单理解为编译器需要遍历 AST 或者其他中间产物的次数）
这个现象的问题在于，这是尾巴在摇狗（本末倒置），这并不是解决方案优先，而是组织架构优先。解决这种问题的思路非常简单，要从实际方案出发，敢于做架构调整：
Recap
若有收获，就点个赞吧
0 人点赞
