Martin大叔那篇著名的微服务文章出来后，”微服务”这个词逐渐进入大众视野，然后一系列关于微服务的框架，治理手段层出不穷，如spring cloud全家桶。
经过这一年多对服务框架和调用链的实践，多多少少有些体会，每次在套用这些名词的时候总会有一种似曾相识的感觉，静下心来想想其实在鹅厂的时候已经接触不过不少相关的套路，那会大叔的文章并没有出来，也没有人把他给总结的这么高大上，这里先堆一些名词，等日后慢慢丰富。
大系统小做
将功能复杂较大的系统，化大为小，减少模块耦合，降低相关联性，用多个独立的进程相互协作来实现整体的复杂系统功能，比如把读和写的功能分成不同的进程实现。
- 微服务思想的精髓
tbus，spp
前者是IEG当时游戏服务器的标配框架，后者是SNG业务服务的标配框架。
两者都共同点是业务进程通过网络或者共享内存与本机的一个代理进程进行通信，该代理进程负责与外部其他节点> 通信，从而对业务屏蔽了网络通信的逻辑，想想这不就是现在service-mesh中的sidecar么。
- service mesh
QZA
由于qzone平台层的模块众多，中间层的业务对接起来不可能都自己去实现一套协议转换，鉴权，频率控制等逻辑，于是qza(qzone access)应运而生
- API网关
CLog
当时这个系统印象比较深刻的用途就是给老板(GM)这类人专门定位问题的，比较模块太多了，一个一个log查起来不现实，只能把log集中存储，按照uin，seq等维度来聚合。
- 染色，调用链
L5
这是个神器，当时SNG基本上所有的业务机器上面都有一个L5-Agent，干啥呢，就是帮你做服务发现，你每次调用下游服务的时候，都会通过api从其共享内存中拿一个IP:PORT，拿的过程就做了负载均衡了，只不过调用者感受不到，调用完下游服务之后，你会上报这次调用的结果(返回码，耗时等)，基于这些上报，当某个下游服务出故障了，他会自动帮你摘除掉该节点，这不就是熔断么。
- 服务发现
- 负载均衡
- 熔断
柔性可用
“结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别的、不同的用户体验，最大限度的保证关键服务的可用性。” 这跟降级的思路基本一致。
- 降级