三、SLA限流的陷阱
如《分布式服务框架》一书第14章14.6总结所说，流量控制是保障服务SLA的重要措施，也是业务高峰期故障预防和恢复的有效手段，分布式服务框架需要支持不同的流控策略，还要支持流控阈值、策略的在线调整。作者介绍了静态流控，动态流控的基本思想。
具体到操作层而言，我们的单机服务器容量一般是针对服务接口粒度。比如A系统有咨询、支付、发放三个主要接口，那么一般而言，在压测的时候有不同的场景组合模型来支持三个接口组合的能力设定，QPS或者TPS。
场景组合\接口名 |
咨询 |
支付 |
发放 |
场景组合1 |
1000QPS |
150TPS |
400TPS |
场景组合2 |
800QPS |
170TPS |
450TPS |
场景组合3 |
600QPS |
210TPS |
500TPS |
如果业务需求判定为重点保障咨询接口，则把咨询设置为最大值比如1000，而支付和发放就会调小，比如支付120TPS。但是如果咨询实际的值大于预期，支付实际又没有预期高，原本期望用于支付的资源可以部分挪用来做咨询，然而现有固定阈值状态下咨询会被限流。于是可以通过动态调整限流策略来做到这一点。期望限流策略同时做到：1保护系统资源 2 保证重点接口的服务能力 3 根据当前的各接口负载，动态调整限流。
再谈谈第二个问题，假设支付接口B的单机TPS测定为300TPS，可能商户m的流量占了60%，如果商户m的流量奇高（某日营销活动），那么商户m的流量就会打满300触发限流导致其他商户均支付不成功。解决方案1是在路由的时候就区分好大商户和普通商户，大商户有专门的服务集群，达到隔离的目标。解决方案2是在接口SLA上面做文章，扩展限流组件的能力，可以支持细粒度的限流，可以通过配置商户参数、表达式来实现。下图即是粗放式限流一类管理界面。
四、参数传递的商榷
林峰在12章总结参数传递策略。包括业务内部参数传递、服务框架和业务之间的参数传递。其中业务流程编排涉及参数传递总结了三种方式：
- 硬编码
- 通过抽象的编排上下文进行传递
- 通过专业的BPM流程引擎进行业务逻辑编排，参数通过流程上下文传递
4.1 线程上下文传参规范
在上下文参数传递中，经过使用ThreadLocal进行参数传递。要特别注意的是ThreadLocal参数清理，以及使用ThreadLocal还存在多线程情况下数据混乱的风险。因此在一些编码规范中约定：
- 本系统内， ThreadLocal变量使用完成后，必须在本系统显式remove。
- 跨系统，接口服务提供方，不能直接或者间接通过ThreadLocal参数提供给服务消费者使用。
4.2 参数透传风险
透传参数也是我们经常使用的一种方案。透传参数看似简单，也有一些容易犯的错。透传参数最大的问题是没有定义那些参数应该在那些系统消费。比如A>B>C>D…E，A、B、C、D系统存在同步调用关系，D发消息给E。一些上下文的构造在A系统创建，本身应该在D系统消费的，结果在C系统不小心被修改了，那么就发生了超出预期的风险。
4.3 非合理使用共享变量
我们来看一个使用扩展字段的例子：
A系统调用B系统的服务，B系统的处理逻辑伪代码如下：
//检查checkInfoMap是否有payInfo对象匹配的内容
List<CheckInfo> pAssertCheckInfos=matchCheckInfos(payInfo,checkInfoMap);
//匹配结果不为空
if(pAssertCheckInfos.isEmpty())
{
//代码省略
return;
}
//清空
payInfo.getInfoMap().clear();
这段代码的问题在于进入if分支后，直接返回；没有执行map的清空逻辑。
A系统继续使用了decisionInfo对象，处理逻辑是拿到大字段map以后直接putAll追加到原有入参map中，导致在某种情况下返回map追加到多个入参map中，而产生超出预期的结果。对象共享有几种方式：本地缓存、静态对象、单例对象、单例bean服务的成员变量等。以下介绍一个本地缓存风险介绍的案例。
在大型并发系统设计中，基于现有分布式编码的经验总结出如下原则：任何对象共享涉及都需要杜绝外部变更风险，有如下几种方式基于自身使用场景去考虑哪种更适合：采用深克隆的方式，采用不变对象模式。
五、服务规模的把握
经常有人问，服务拆多大合适？有人说微服务的微究竟是多”微”？林昊在前一段有一篇文章《大部分公司并不需要微服务》，一个单一应用的复杂度远比N个应用组成的分布式系统简单、快速的多；一旦进入分布式的坑，在技术上就不得不有比较大的投入，而对于一些处于中小规模的公司而言，完全没有必要。
我觉得在几十名研发的公司，可能还真的不需要做服务化或者微服务。在支付宝几百研发人员的时候，应该还是2个主要系统，一个前台业务，一个后台系统。
回到多大服务规模合适，可以看看康威定律，系统架构往往和组织架构相关，反之亦然。我们回头看3人一组的小team能cover多少system？如果把system拆分为service（服务），可以再次计算。比如1个人cover 1-2个系统，如果平均1个系统10个服务的话，那么单人管理的服务在20以内的级别；3个小组管理的服务应在100个之内。
服务本身的拆分粒度也要在管理复杂度上做权衡，业务领域的内聚上做权衡。服务变多，链路变长，研发效率反而会下降。我们应尽量降低依赖。
六、服务调用跟踪
众所周知，trace架构基本都源自Google Dapper。
下图为高德在基于trace基础上做的场景应用，比如服务状态自我诊断、监控追溯等。
上图为支付宝app通过无线网关的trace示意图，包括应用链路，文件存储。应用链路包括rpc调用和消息服务。《分布式服务框架》一书，林峰特别对服务调用链价值进行了汇总，体现了对于不同角色，服务调用链路跟踪的价值所在。
开发：
架构优化
消除不合理依赖
性能优化
还可以补充容量评测、设计变更分析等
测试：
识别调用流程
优化测试用例
关键路径覆盖率
还可以补充自动化端到端测试
运维：
故障定界
故障定位
提前预警
易故障点识别
七、分布式事务
todo
声明：
本文部分插图引用网络公开资料，包括高德稳定性架构实践（雷娃）、支付宝无线-从前端到后端的服务治理 以及 阿里妈妈全景业务监控平台Goldeneye。
