在后台服188务体系8146中，基础设1931施是运行在业务逻辑之下的计算、网络、存储资源以及通用的基础服务。如果没有完善的基础设施，业务团队只能以"小作坊"形式运作，具有较弱的服务治理能力，产生效率较低，大部分时候只是为了满足业务短期需求，如果出问题了再安排人力来优化，  但是并不能很好收敛架构不完善带来的效率和质量问题，特别对于ToB的场景，质量和口碑犹其重要，不应该有持续的服务质量问题。针对如何实现一套完整的基础设施及其应具备的能力，下面做了一些思考和分析。

基础构架的设计思考

总的来说，业务所需要的基础设施能力就两个：高效开发测试和高质量的运营。具体有：

1. 相互独立又稳定的开发测试环境。不管是新功能开发还是后期迭代优化，开发测试过程很需要的一点是能够快速运行代码并验证执行结果，这里要求基础架构有高效的部署方式和基于账号信息的流量管理功能。
2. 丰富的公共服务组件。开发最好可专注于业务逻辑开发，而不重复造各种不可靠的轮子，这需要有稳定可靠的名字服务、日志、监控、RPC、网关能力等基础服务组件。
3. 安全高效地灰度变更。从经验上看，大部分的线上故障都是变更导致的，所以需要一种可靠低风险的灰度方式，实现方案主要两种：a)支持多set，不同用户流量在不同set，如果出问题尽量少地影响用户。b）单set之内，支持蓝绿灰度方式，发布后的版本流量从0开始增加，无异常再增加到100％。
4. 统一而又灵活的框架能力，有标准的灰度发布、容灾容错、日志、监控、链路追踪等运维能力，但是又不会限制只使用某个框架，同时基础组件可以根据业务需求有一定插件化定制能力。
5. 考虑持续运营的能力，默认有监控告警、弹性伸缩、多地容灾的架构能力，开发不应该花费大量时间来排查和处理线上问题，各类组件异常有容灾备份而不影响服务质量。

如上图所示，开发和测试同学可以基于账号信息路由到自己的版本，发布变更时可以控制新版本的流量比例（基于账号hash或其他维度）

基于以上考虑，设计了下面的构架图：