标准化体系建设（下）：如何建立基础架构标准化及服务化体系？

看新闻很累？看技术新闻更累？试试下载InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

本篇文章选自极客时间“赵成运维体系管理课” 付费专栏中的其中一篇，专栏内容主要聚焦在分布式软件架构下的应用运维这个领域，更多的是作者对运维的一些架构思考，主要分成四部分: 应用运维体系建设、效率和稳定性等方面的最佳实践、云计算方面的思考和实践以及个人成长与趋势热点分析。专栏详情请点击查看。

前面我们一起讨论了为什么要做标准化，标准化的套路是什么，并按照套路进行了基础设施和应用的标准化示例。我想这些内容可以帮助我们举一反三，尝试着应用到实际工作中了。

今天，我继续跟你聊基础架构标准化的问题，但是今天我计划不谈如何进行架构标准化的细节，而是想强调一下基础架构标准化的重要性，因为从我个人的经历和我实际观察到的情况来看，这块的问题会更普遍一些，而这一部分又影响着后续一系列效率和稳定性平台的建设方案。

同时，如果说上次我们讲的基础设施和应用标准化是运维团队职责的话，那今天的内容就是架构、开发和运维共同的职责。

常见的分布式基础架构组件

让我们先一起列一下，微服务的分布式架构下，涉及到的主要基础架构组件有哪些。

• 分布式服务化框架，业界开源产品比如 Dubbo、Spring Cloud 这样的框架；

• 分布式缓存及框架，业界如 Redis、Memcache，框架如 Codis 和 Redis Cluster；

• 数据库及分布式数据库框架，这两者是密不可分的，数据库如 MySQL，MariaDB 等，中间件如淘宝 TDDL（现在叫 DRDS）、Sharding-JDBC 等。当前非常火热的 TiDB，就直接实现了分布式数据库的功能，不再额外选择中间件框架；

• 分布式的消息中间件，业界如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等；

• 前端接入层部分，如四层负载 LVS，七层负载 Nginx 或 Apache，再比如硬件负载 F5 等。

上面是几类主要的基础架构组件，为了便于理解我以开源产品举例。但在实际场景中，很多公司为了满足业务上的个性化需求，会自己研发一些基础组件，比如服务化框架、消息中间件等，这个情况在有一定技术实力的公司里比较常见。不过大部分情况下，我们会基于这些开源产品做一些封装或局部的改造，以适应我们的业务。

基础架构组件的选型问题

关于基础架构组件，业界可供我们选择的解决方案和产品是非常多的，但是选择多了就容易挑花眼，反而不知道从何入手。我们大概都会遇到同样的问题，是自研还是选择开源产品？有这么多的开源产品到底该选哪一个？

按正常的思路，一定是先组织选型调研，然后进行方案验证和对比，最后确认统一的解决方案。

但是，由于开源产品的便利性，以及开发同学对技术探索的好奇心，实际情况往往是，整个大的技术团队中，不同的开发团队，甚至不同的开发人员，会根据开发的需要或个人喜好，选择不同的开源产品，在没有严格限制的情况下，甚至会尝试去自研。

按照我的观察，这个问题特别容易出现在微服务架构引入初期。在这个阶段，团队组织架构按照业务领域进行切分，产生一个个与业务架构匹配的小规模技术团队。每个小团队所负责的业务相对独立，自主权就会变大，如果这个时候整个团队中没有一个强有力的架构师角色去做端到端的约束，就极其容易出现上面的这个问题，并且会一直扩散蔓延下去。

相比之下，成规模的大公司在这一点上做得就相对严格一些，当然也可能是因为之前尝过苦头，所以后来变得越来越规范了。所以这一点也是每个技术团队在引入微服务架构时要提前关注的。

我们以分布式服务化框架为例，我之前遇到的一个实际情况就是，整个大的技术团队选型时以 Java 技术栈为主，毕竟这块有很多的业界经验和产品可以借鉴参考。但是有的团队对 PHP 特别精通熟悉，就想用 PHP 去做微服务，有的团队对 Go 感兴趣，就想尝试 Go 的微服务。

从单纯的技术选型上来看，选择什么语言并没有严格的标准。而且在技术团队中，我们也应该鼓励技术多样性和尝试新技术。不过这里要有个度，我暂时先不细说这个度在哪里，我们先来看看，假设没有统一标准的约束会带来什么问题。

技术的应用，一般都会随着应用场景的逐步深入和业务体量的增长，逐步暴露出各种各样的问题，我们分两个层面来看。

本篇节选自“赵成运维体系管理课” 付费专栏文章，请移步极客时间赵成专栏查看完整文章并欢迎你留言并与作者一起参与讨论。

赵成，美丽联合集团技术服务经理，公众号“Forrest 随想录”的作者，多届 ArchSummit 运维专题明星讲师和优秀出品人，EGO 杭州分会会员。目前专注于云计算和人工智能时代的运维转型和提升。2018 年 1 月在极客时间上开设“赵成运维体系管理课”。专栏详情请点击查看。