架构标准化影响着后续一系列效率和稳定性平台的建设方案。
架构标准化是架构、开发和运维共同的职责。
常见的分布式基础架构组件
微服务的分布式架构下，涉及到的主要基础架构组件
- 分布式服务化框架，业界开源产品比如 Dubbo、Spring Cloud 这样的框架；
- 分布式缓存及框架，业界如 Redis、Memcached，框架如 Codis 和 Redis Cluster；
- 数据库及分布式数据库框架，这两者是密不可分的，数据库如 MySQL、MariaDB 等，中间件如淘宝 TDDL（现在叫 DRDS）、Sharding-JDBC 等。当前非常火热的 TiDB，就直接实现了分布式数据库的功能，不再额外选择中间件框架；
- 分布式的消息中间件，业界如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等；
- 前端接入层部分，如四层负载 LVS，七层负载 Nginx 或 Apache，再比如硬件负载 F5 等。
基础架构组件的选型问题
是自研还是选择开源产品？有这么多的开源产品到底该选哪一个？
按正常的思路，一定是先组织选型调研，然后进行方案验证和对比，最后确认统一的解决方案。
我们以分布式服务化框架为例，我之前遇到的一个实际情况就是，整个大的技术团队选型时以 Java 技术栈为主。
如果技术选型不一致会出现很多问题。
所以，这个时候我们需要做的，就是对基础架构有统一的规划和建设。原则上，每种基础组件只允许一种选型，至少就能满足 90% 甚至更多的应用场景。
比如数据库就只允许使用 MySQL，然后版本统一，同时配套的中间件也必须统一，其它的关系型数据库没有特殊情况坚决不允许使用，如果遇到特殊情况具体分析。
基础架构的服务化
对基础架构组件做了统一标准后，下一步要做的就是服务化
这里以 Redis 缓存为例。
- 创建和容量申请；
- 容量的扩容和缩容，新增分片的服务发现及访问路由配置；
- 运行指标监控，如 QPS、TPS、存储数据数量等等；
- 主备切换能力等等。
以上这些，假设都依赖 Redis 提供的原生能力来做，基本是不可维护的。所以必须要基于这些原生能力进行封装，结合运维场景，将能力服务化，这样就大大提升了使用方的便利性。
个服务化的过程其实就是 PaaS 化的过程。换言之，如果我们能把基础架构组件服务化完成，我们的 PaaS 平台也就基本成型了。
运维的职责是什么？
可以归纳为两步：第一步是基础架构标准化，第二步是基础架构服务化。
这个时候，运维必须要有意识去做的两件事情。
1.参与制定基础架构标准，并强势地约束。在这里运维作为线上稳定的 Owner，发挥约束作用有可能会比业务架构师这样的角色更为有效。另外，由于历史原因或其他种种因素造成的已有架构标准不统一的问题，是需要开发和运维共同合作去改造的。这里面如何保持良好的协作，制定统一的路线图也是非常重要的。所以这里强制约束是一方面，同时也要提供工具化的手段来支持开发的改造，也就是下面这个动作。
2.基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人。这个事情是驱动运维转型和改进的动力，也是运维能够深入了解架构组件细节的有效途径。同时，要注意到，如果不朝着服务化方向发展，运维将始终被拖累在这些基础组件的运维操作上。
总结：
基础架构标准化是影响着后续一系列效率和稳定性平台的建设方案。
对基础架构有统一的规划和建设。原则上，每种基础组件只允许一种选型，至少就能满足 90% 甚至更多的应用场景。
基础架构的服务化，基于redis等等这些组件对原生能力进行封装，结合运维场景，将能力服务化，这样就大大提升了使用方的便利性。基础架构组件服务化完成，我们的 PaaS 平台也就基本成型了。
运维的职责是：第一步是基础架构标准化，第二步是基础架构服务化。
1.参与制定基础架构标准
2.基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人。