对于基础组件我们要做什么？

一、从常见的分布式基础组件说起

在微服务架构下，涉及到的主要基础架构组件包括：

• 分布式服务化框架。比如，Dubbo、Spring Cloud；
• 分布式缓存及框架。比如，Redis、Memcached；
• 分布式消息中间件。比如，Kafka、RabbitMQ、ActiveMQ以及RocketMQ等；
• 数据库以及分布式数据库框架。比如，MySQL、MariaDB、TiDB等；
• 分布式文件系统以及存储框架。比如，HDFS、GlusterFS、Ceph等；
• 前端接入层。比如，LVS、Haproxy、Nginx等

上面提到的这几类基础组件，基本上可以覆盖绝大多数的使用场景。此外，业界一些优秀的开源产品也可以满足我们绝大多数的业务需求。当然，一些公司为了满足业务上的个性化需求也会进行自研。

二、为什么要统一基础组件

关于基础组件，业务可供我们选择的解决方案和产品非常多，但是选择多了就容易挑花眼，反而不知道该从何入手。按正常的思路，一般会先组织选型调研，然后进行方案验证和对比，最后确认统一的解决方案。

然而，在实际情况中，一些技术团队的不同开发人员，往往会根据个人喜好或开发需求，选择不同的开源产品。这样，随着使用场景的逐步深入和业务体量的增长，就会暴露出各种各样的问题：

• 在开发层面，业务开发人员需要投入大量的时间、精力研究和适配各种开源产品，很难聚焦于业务需求的开发。
• 在运维层面，当我们考虑建设一个统一的效率和稳定性体系时，需求花大量时间去适配多种不同的组件。

因此，在选择基础组件时，我们要做统一的规划和建设。原则上，每种基础组件只允许一种选型，这至少能满足90%甚至更多的使用场景。如果遇到特殊情况就做具体的分析和处理。

三、基础组件服务化

在我们统一了基础组件之后，下一步要做的就是服务化了。因为这些组件都只提供了简单的维护功能，并且许多维护工作都需要在命令行才能完成，这时我们就要考虑把这些组提供的维护API进行封装，以提供更加便捷的运维能力。

以Redis为例，我们需要提供的维护能力会有：

• 创建、申请容量；
• 容量的扩容和缩容；
• 新增分片的服务发现以及访问路由配置；
• 运行指标监控；
• 准备切换能力等；

以上这些操作，如果都依赖Redis提供的原生能力来实现，那基本是就是不可维护的。因此，我们必须对这些原生能力进行封装，结合具体的运维场景，将能力服务化，这样就可以大大提升使用方的便利性。

四、小结

对于基础组件，我们要做的事情有两件：

• 标准化。参与基础组件的选型，建立的统一的标准。
• 服务化。建立服务化平台，让开发人员借助平台的能力自助完成做基础组件的操作需求。