百度代码配置化实践：配置化是业务架构三化之一

按：业务架构有三化——配置化、产品化、自动化，配置化解决业务系统灵活性、动态可变的问题，产品化解决工具复用提效的问题，自动化让机器工作、解决人力成本问题。本文来自百度刘志伟、韩炳涛两位同学对百万行配置化经验的分享，具备有一定总结的抽象性。

 

背景

互联网软件市场是一个快速变化的市场，优秀的服务层出不穷，所以互联网软件公司需要快速推出服务抢占市场、并且能够快速响应用户的需求，否则就面临被淘汰的命运。这跟达尔文主义的观点是一致的：

It is not the strongest species that survive, nor the most intelligent, but the ones most responsive to change.

大型且成熟的互联网产品为了能保持适应快速变化的市场则尤其困难，比如百度某广告系统由百万级的 C++/JAVA 代码构成，上百人工作在上面，并且每天进行着大量的业务需求迭代。由于系统演化多年，代码实现常常耦合，代码上的迭代容易引发问题，相应的回滚处理都比较复杂。静态代码构成的大型系统在编译、重型的测试上都耗费很多时间。系统不断重启升级，也影响了对外提供服务，甚至会影响收入。为了能够使复杂系统仍然能快速应对变化，我们进行了一系列服务化以及配置化的实践。

从14年逐渐兴起的微服务架构是作为面向服务架构的一个特定方法，强调的是小而独立的服务，根本上还是对从领域里抽象成服务并进行管理。从快速应对变化的视角上看，微服务的技术异构性使得我们在面临不同的问题的时候，能够选择最适合的技术进行快速解决，以及能对服务进行组合，从而快速实现针对不同的客户提供不同的功能。除此之外，微服务在弹性、扩展性上等等都有很好的优势。此类的文章已经比较多，本文重点讲述配置化架构的实践。

什么是配置化架构

在软件系统中的配置通常指的是软件系统中的对象、对象属性、数据等，借助独立于软件系统的标准数据格式语言，比如xml、json、yaml，进行表达，从而能够在只改变标准数据格式语言且不改变软件系统本身功能的情况下，就能改变系统行为的方式。

应用配置的场景非常多，比如在百度用C++开发的搜索引擎控制模块，把用户查询的关键字通过消息，发送到后端存储服务上进行检索。查询消息的超时时间，以及消息在超时后需要重新尝试的次数，都是参数类的数值。我们可以通过C++代码里直接用常量表示，也可以通过配置的方式指定。他们的不同点是，一旦数值发生变化，静态代码需要做重新编译、重启升级、往往还需要通过繁重的测试以及很多的人工操作。配置为快速变更提供了可能，不需要做编译，也可以通过动态加载的方式避免系统的重启，甚至如果变更是安全可控的，繁重的测试以及很多人工操作都可以节省。再比如开关，借助于Google 的 Gflag，我们可以在运行时灵活的控制某个功能的关闭和开启。

架构有着非常多的定义，Roy Thomas Fielding 在 < architectural styles and the design of network-based software architectures > 把软件架构定义一种架构元素（组件、连接器、数据）的配置表示。这里配置的语义变得更宽泛了，已经不再是指单纯的标准数据格式语言（xml, json, yaml）类的配置，而是一种能够描述架构的语言。使用配置更宽泛的语义，配置化架构定义如下：

配置化架构是指可配置的方式构建软件的方法。它是在领域建模的基础上，以配置表述业务，以配置组织架构元素（服务、组件、数据），并对配置进行规范化、自动化的管理。

配置化架构的基础是对领域的抽象以及软件系统的高度的自动化。

优缺点

配置化架构的开发方式，相对于代码开发，无论是在服务的级别，还是在组件内部的级别，甚至是内部参数，都可以在不对软件功能进行变更的情况下，就能实现软