第一个：两周建成立体化监控体系：为什么需要监控？因为重构过程中，随时有可能出问题，所以需要一个监控系统能随时看到重构的链路情况。为什么是两周？
因为重构对时间其实是有要求的，需要快速完成。如何在两周之内建成一个立体化监控体系呢？有几点：1、指标要极简2、可视化3、管控全网化（规则报警、一键定位、洪峰控制、业务降级），4、统一日志模型，针对重构系统的变化，要保证监控是准确的，所以需要对服务模型抽象出三层（服务的使用者、服务的提供者、服务的集成者）打日志，每个服务的接口都会打digest摘要日志。实现过程中，会请架构师或资深的技术经理搭好插件化框架，完成日志模型搭建、异常体系的建设，领域模型，对输出结果的阐释策略。后面程序开发时，开发人员只需要开发对应的插件即可，这样就将程序的设计和重构变成了工厂的批量化生产，所以这个维度上其实就能减少很多风险。做到以上几点，才能保证重构过程比较平稳和风险可视化。
第2个案例，全链路压测：我们的压测系统经历这么几个阶段：
首先是线下压测阶段，这会面临3个问题：测试环境和生产环境配置不一致（比如生产环境配了10个数据库，而测试环境只有5个）；测试环境和生产环境数据结构不一致，（生产环境有些用户可能有50个订单行，而测试环境基本上为了测试方便，可能只构建了1个订单行）；用户访问路径不一致（比如生产环境用户从4级页到收银台有4步，而测试环境直接从金融App进来1步完成。漏斗不同决定了大促的流量比例不同，比如前面有1万TPS，经过3层漏斗只剩1000TPS如果只有2层漏斗，可能剩下5000TPS，对资源的消耗是不一样的）
第二个阶段，我们开始做生产憋单压测（比如代扣的订单憋在一起，从收单到支付服务到银行，都可以进行压测，但是对用户进入收银台前面的路径获取不到，基于这个缺点），这样可以实现部分链路的生产环境的真实流量压测；
第三节阶段就是，我们目前正在使用的全链路生产压测，就是把全链路串起来；当时我们做的时候，需要解决3个问题：（1）服务的用户商户怎么办？（2）银行不配合压测（3）如何保证支付链路系统的配置准确。解决方案是：在易购建立测试商户和账户，配置虚拟银行，配置影子库影子表，改造中间件，增加影子库单号判断，做到与生产用户数据隔离。
在多活这个方面，我们也经历了几个阶段的发展，初期因为业务量小，我们做了一个稻草系统，它是一个最小可用支付系统，只关注80%主要的银行和支付工具，即便出问题时，能保证核心链路仍可用。这个系统在交易量大肯定是有问题的，下一阶段就开始做支付核心链路failover，但是仍不能解决机房出问题（如停电问题，网络设备问题等）。
所以后来做了多活，要做多活就要解决几个核心问题：跨机房耗时问题、依赖服务部署与治理、研发体系配套改造、故障切换的工具支持。我们的解决方案主要是：
1、支付链路单元化;
2、消息同步服务化;
3、依赖服务做多活部署;
4、研发体系的配套支持，支持发布到金丝雀环境等；
5、机房选址，跨机房调用其实存在很大延迟；
6、容灾能力，支持机房级容灾，按系统、按链路容灾；
从单机房到多机房，在架构演进过程中，也要支持容灾，因为演进过程中要做系统发布，逐步切流量。比如整体流量先切换白名单用户，再切换1/256,1/8,1/4，到1/2等，也可以针对单个系统的切换，单个模块的切换等（包括数据源的动态切换，以及切换过程中，安全等问题），便于在建设过程中控制风险；
热点防护包括3部分：
1、发现热点，感知热点源，通过埋点，关注请求，关注整个链路依赖的资源；
2、热点诊断，主要通过实时分析，离线分析，上下游分析;
3、热点治理，最粗暴的直接限流，这个是有损服务，是一刀切。
可以稍微再优雅一点，进行故障隔离，比如由于场景1导致的问题，可以直接把场景1切调，对其它场景没有影响，这样可以做到稍微精细化一点；业务场景优化，比如账务核心收支账户分离；热点结构优化，比如说我们在收银台上有一个活动，只取前1000名满100减50，其他人没有资格，其实是通过优化缓存结构实现的；热点拆分，对数据库进行分库，对数据表进行分表， 对记录进行缓存机制处理。基础服务包括统一日志，服务的SLA，决策支持；应用工具包括系统级的紫金大盘、产品级的地动仪，这两个其实是可视化工具，用来观测治理之后的效果。
接下来讲从100tps到20万tps的实践过程。
横向看，从总体架构优化到应用程序优化到数据程序优化到技术组件的优化；纵向看，深入到每一个架构，从收银台到收单到支付服务到渠道到账务核心到清结算进行优化。应用层看链路能否缩短，再看内部服务能否治理，再到线程池调优，去事务。
数据层优化，需要考虑收益，比如SQL优化排第一位，因为比分库分表的收益来的快。原则是能用单库尽量用单库，不能用单库时，才考虑分库分表。DB配置参数优化，可以优化引擎参数。因为优化过程会产生资源消耗，所以仍然要考虑业务目标。基础技术平台优化，要遵循体系，服务的本身，依赖方，服务方。
中间是RSF分布式服务框架（内部通过这种服务来进行路由和调度。数据方面，分库分表组件和缓存；通信方面，调度组件）的优化。接下来是存储，如SSD，以前是普通硬盘，那么IOPS会比较低，如果本次优化目标是提升2倍，那么只要更换SSD，速度快，成本低，对用户也没有损伤。
闭环验证中心，这个是我们做性能优化的一个亮点：特别是重构、性能优化的时候，需要快速知道结果是不是我们想要的，下面的服务日志、调用日志都是比较通用的。
监控决策中心：提供灰度方案，移动端应急管控。虽然日常有规则管控，做SLA、流控，但是关键的核心系统出问题（如支付服务），仍需人工介入确认是否执行降级和流控，因为一旦流控，会对用户产生影响。我们最近也在建设大促机器人，实现自动巡检，和智能的治理，这个后面会讲到；
然后需要验证大屏，可以直接看到对门店或交易是否有影响。 其实在做系统性能优化的时候，也会伴随研发组织与研发过程的“性能优化”；
这个我有一篇文章《业务需求极速变化的高并发金融系统性能优化实践》，里面有详细的分享，主要介绍苏宁金融对业务需求极速变化的高并发金融系统进行性能优化的实践经验，主要包括：智能监控系统，瓶颈点驱动的性能优化，全局规划驱动的性能优化以及研发组织与研发过程的“性能优化”；核心技术点包括瓶颈点的可视化诊断，瓶颈点治理，热插拔架构设计，链路failover设计，应用N+X设计，异步化，数据库单点与热点账户防护；也包括从网络，中间件，应用层，数据层，DB的横向优化方案；以及从架构，代码，会话，缓存，线程与队列，事务，堆内存与GC的纵向优化方案，横纵向结合的体系化解决方案实践；
以上讲述了指导思想和方法论，具体需要怎么操作呢？
可视化瓶颈点很重要，这里我举一个示例，比如银行网关系统，调用22次，透明化每一次调用，调用依赖系统多少次，每个系统的SQL有多少，这样可以清晰的可视化链路，保证快速知道哪里出了问题。然后就可以进行庖丁解牛式的优化了；
为什么要做故障自愈？因为出问题时，老板一定会问：影响多少用户？影响多少场景？什么时候恢复？那个时候会非常紧张，也忙于处理生产问题，无法快速回复老板问题，也无法快速想出优化方案，所以需要有个地方可以看到问题影响面、执行什么操作可以恢复。实现这样的系统需要三部分：故障源感知、智能诊断引擎、故障治理。
故障源感知：指标分为3类，业务指标、系统指标、基础指标。观测指标发现，几类容易出问题的地方：
（1）系统变更，出故障时首先问，昨天有没有发布？系统变更占权重很大；
（2）突发业务量，可能某个商品突然很火爆，大促前估不准业务量；
（3）操作失误，拓扑获取和链路追踪，知道调用链出了什么问题；
（4）单点追踪；
（5）安全攻击；
通过诊断业务系统暴露的问题，可以将其指标化，才能便于工作的落地与执行：比如高可用时，不能定9999多少个9的目标，可以定MTTR=1分钟的目标。以前会定A完成日志模型，B完成SQL优化，C完成异常治理等，但一段时间后发现并没有解决问题，后来我们定了“北极星”指标MTTR=1分钟，这样技术经理自然的知道需要完成日志模型优化等工作。通过这一个指标去牵动其他指标的达成。
故障治理有3方面：场景修复、链路修复、服务修复；服务修复需要提前定义执行引擎，WAF防火墙到负载均衡到RSF到SCM到TCC到DB，形成一个体系。出不同问题，会执行不同的应急预案。最后针对不同的业务流和资金流，做异常数据比对。
机器人巡检，因为大促对我们来说是很重要的节点，每次也耗费很多人力物力，可以实现宏观上系统的整体化构造，微观上看到每个系统的状态。
全网可视化作战沙盘，上面的几个指标被称为“北极星指标”，不是开发部门自定的，是根据集团战略目标分解的。战略目标分解到研发中心，研发中心分解到每一个项目。右上角的+号有3个功能：1、全景的产品视图，2、系统的治理，3、考核，每做一个优化需要考核，这样每个团队能形成同一个目标去做事。
这样就将人，事全部链接成了一个整体，所有的工作都将形成闭环，同时所有决策层都能可视化的看到；便于所有工作的快速推进和落地；
我写的一篇《从百亿到万亿：如何打造一支承担企业战略使命的研发团队》文章中，有更加详细的分享，欢迎一起交流。
