上线新技术栈要经过怎么样的流程验证，如何设计与打通，评判一个数据架构的好坏有哪些？
引入新技术的门槛相对是比较高的，通常来说会和已有的方案不对等，不够那么公平，如果新方案的整体表现和现有方案差不多，那么推进改进的落地性就没有那么强了。
在开始之前，有一个点非常重要，重要到不谈这个就是空谈，这也是今天圆桌讨论中玄姐提出的，那就是当前的痛点，如果没有很明确的痛点，那么这个结果也是随机结果，落地效果也会相去甚远。
以我的经历来看，比如我们所做的商业数据库向开源数据库的架构演进方案，痛点是现有的方案在中长期存在瓶颈，比如用户量翻番，业务规模翻番，是很难通过资源扩展去适配的，所以这是一个战略方向，重要且不紧急。新技术方案的体系化落地大体经过了3个步骤，功能验证，架构改造，数据迁移和业务切换
我来详细说明一下：
1.功能验证：功能验证是我们进行方案验证的一个立足点，首先保证对于业务的改造范围较小，至少在整体功能设计上要和原有的方案保持一致，在功能验证方面，我们走了一些不得不走的路，比如将存储过程逻辑幂等改造从商业数据库整体重构改造到开源数据库，对于技术沉淀较好的公司和团队，这一点就可以比较平滑的跨过去，另外对于应用逻辑调用层面，原本存储过程包干的模式改造为轻量级SQL的模式，对于流量的变化如果没有精确的数据支撑，也是很难推动落实下去的，而在访问模式上，我觉得可能不是一个最纠结的部分，如果能够平滑支持是最好的，而如果有更高的功能目标，这一点是可以平衡的。
2.架构改造：以我们做数据库的整体架构改造为例，某一个业务的读写比例都很高，对于业务延迟相当敏感，在上线前夕明确了读延迟在1毫秒以内，写延迟在3.5毫米以内，在保证功能幂等的前提下，我们对整体的方案进行了很多细致入微的优化调整，从读写分离到数据架构的改进，甚至是部署架构的调整能够提升10%的性能，也是极大的改造，最近将读延迟控制在了0.8毫秒左右，写延迟控制在3.2毫秒左右，整体满足了需求，而且随着业务规模的增大，也具备水平扩展能力。
此外，这个阶段对于事务的使用时可以理性看待的，很多使用习惯中对于关系型数据库都会默认启用事务处理，但是显然对于流水型业务来说，是完全可以做到事务降维的改造，这里需要衡量的是你是不是一定需要所谓的OLTP场景和OLAP场景，因为不是所有的业务都需要用着一把尺子来衡量。
3.数据迁移和切换，我觉得这是方案落地最关键的因素，如果一个方案能够保持现有的业务使用模式，而且能够平滑切换，那么对于方案的落地式非常友好的，但是对于方案的设计层面势必需要考虑两个大的方面，第一是数据迁移，第二是业务切换。数据迁移涉及数据量，数据架构的差异，这个过程毫无疑问是异步模式，同时需要基于增量和实时稽核模式对于数据质量进行把关，整个过程的可行性是通过尽可能通过异步流程化实现，即不需要依赖每一个步骤的实时性；业务切换可以基于旁路策略，实现读流量和写流量的调度切换，达到对于业务相对平滑无感知到切换目标。
一个好的架构师的职业素养
我觉得对于很多DBA同学来说，谈架构有优势有劣势，优势在于DBA的工作离架构很近，因为DBA的工作内容包括运维管理，这部分管理工作本身需要更好的理解数据库原理，而数据库原理中很多都是组件，服务，体系化的形式，所以DBA的工作实战中架构思维的培养和提升是具有先天优势的。劣势在于这种思维是具有自驱力去不断推进，如果是画地为牢的思维模式，即看到很多方案都想去单一的适配，其实思维模式会很局限，典型的例子就是拿着锤子看到的都是钉子。
对于很多DBA同学来说，入行门槛相对比较高，很多都是半路出家，对于职业发展转型来说，开发技能整体水平不高，这是需要强化提高的一个方面。
架构的角度看待问题，看待问题需要用一种更高的视角，更全面的看待问题，透过现象看本质，不是解决了当前的问题就是万全之策，架构改造整体是痛苦的，培养起来也很难。
对结果负责，能够对结果负责，而不只是“指点江山”，只有建议，无法落地，对于架构师能力养成是很重要的，这其中的一个因素就是自驱力，自驱力无可厚非，需要有时间的沉淀。
场景折中，这是今天听玄姐的一个理念，非常认同，很多架构不能直接被拿过来，不同企业规模，业务场景都不能完全适配，需要见招拆招，能够灵活的使用和应用，同时满足不同阶段的目标需求，这是一种很强的能力，毕竟一切脱离场景的架构都是耍流氓。
架构逆向思维，很多架构方向都希望做得更多，支持的更加全面，有一种逆向思维值得参考，那就是做得更少，且不脱离场景。比如我们在做的一个架构改造，本来基于大量事务，存储过程的冗余调用，OPS非常高，有几十万，但是通过逻辑改造，做了事务降维，调整为轻量级SQL调用，整个OPS一下子降到了2万左右，这是一种非常有效的思考模式。
