再读《架构整洁之道》

前一阵子读了 Robert C. Martin（Bob 大叔）的大作《架构整洁之道》，觉得挺有意思，但很多地方没细看。五一假期，拿起来重读。

说说读这本书的几个收获吧：

收获 1：SOLID 原则

第一遍刚开始读，最大的感受是，这东西离我好远！这辈子就没听说过 SOLID 原则，但写了这么久代码，不也好好的吗？为什么要整这么多抽象、枯燥的原则把人绕晕？

后来看了一些关于设计模式的书，这才逐渐发现，SOLID 原则的确是很有道理。

不过不得不说，SOLID 五原则的重复性非常强。其实我觉得，它们归根结底就是在说一件事：

软件开发中，要把不变的部分和常变的部分分开；要把不一起变的部分分开。

这么说还是有点绕，下面具体解释一下：

• 自移动端兴起之后，前后端分离已经非常普遍。前端和后端显然是“不一起变”的，比如为了美观，前端可能经常需要改版，但后端可能根本不需要变。从这个角度上来说，前后端分离显然是符合“单依职责原则”（Single-responsibility Principle）的，虽然这个原则通常是指更微观的组件，比如一个类或函数；
• 假设现在出现一款超大屏手机，非常火爆，需要增加对该屏幕尺寸的支持，但功能完全不变。这种情况下，首先后端代码了手机，还需要支持 iPad。除了屏幕需要适配，其他功能完全不变。在这种情况下，首先后端代码不应该改动，其次绝大部分前端代码也不应该改动，只是应该“加上”一些用来适配超大屏的代码。这样就符合了“开闭原则”（Open-closed Principle），即增加新功能时应避免修改负责原有功能的代码，而只是新增代码；
• “里氏替换原则”比较简单：派生类（子类）对象应该能够替换其基类（超类）对象。相对来说，基类（通常是接口）是不常变的，而派生类（通常是实现）是常变的；而保证派生类能替换基类，就是说即便派生类变了，我还是可以像之前一样调用基类，而不需要修改调用方式。这样就把“派生类的变动”给系统带来的影响降到了最低；
• “接口隔离原则”（Interface Segregation Principle:）和“依赖反转”（Dependency Inversion Principle）也差不多讲的是一回事，就是要用接口！如果大家都只依赖接口而不是具体的实现，那么在具体实现变化时，就可以尽量保证接口不变，把对系统的影响降到最低。

总之，一个设计良好的系统就是，把该分开的部分都分开了，这样在增加新功能的时候，只需要修改其中的一小部分，而不会对系统的其他部分造成影响。

当然，分得越细架构就越复杂，从而造成理解和维护上的成本。所以也不是越细越好，要根据实际情况权衡。

收获 2：要把业务逻辑和具体技术分离

一个很好的例子

关于业务逻辑应该和具体技术分离，Bob 大叔举了一个特别好的例子：有一次他设计一个系统，首先编写业务逻辑部分，并且不假定和任何特定数据库对接。这样就非常灵活，之后无论对接任何类型的数据库，甚至根本不需要数据库（Bob 大叔的例子最后就是没有加数据库），都不需要很高的维护成本。

相反，按照大多数人的做法，一开始就做技术选型，选好一个特定数据库（比如 MySQL）；开发过程中也没有很好地把业务逻辑剥离出来，导致之后如果需要更换数据库，成本会很高。

当时读完，觉得这个例子挺有意思，但又离我们很远。因为我从来就没遇到过“需要更换数据库”这样的事情，而且如果真是这样，那一开始就应该把数据库选好才对呀！

但就在前两天，五雷轰顶一般，我突然意识到：我们自己手头这个项目就面对着同样的问题！！

我们遇到的问题

我们虽然没有数据库的问题，但却遇到了一个非常类似的问题：搜索引擎。

我们的站内搜索，目前是基于 Lucene 做的。但 Lucene 有个很大的局限：不支持分布式。这也是为什么会有 Elasticsearch，ES 就是在 Lucene 基础上构建的一个分布式搜索框架。同样的还有 Solr，另一个基于 Lucene 的分布式搜索框架。

而我们直接用 Lucene，相当于放弃了分布式的支持。这就意味着，每个服务实例都需要加载全部索引！随着内容的不断扩充、索引规模的不断增加，这样肯定是会出问题的。

如果使用 ES 这样的框架，只需要简单的配置，就可以实现索引在各节点上的均匀分布，这样每个服务实例只需要加载一小部分索引，负责对这一小部分内容的搜索就可以了。

但迁移到 ES 又谈何容易！由于我们没有很好地把业务逻辑和具体技术剥离，代码和 Lucene 耦合严重。迁移到 ES 意味着大规模重写，在目前的人手和需求量的情况下，显然是不现实的。于是这个问题一拖再拖，不知道要拖到什么时候才能解决。

首先，不得不承认，一开始选择 Lucene（也不知道谁选的）就是个错误。

但同样重要的是，架构上没有做到业务逻辑和具体技术剥离，导致更换技术成本非常高。

现在看来，我们这个项目的情况和 Bob 大叔举的例子何其相似！搜索引擎，无非就是一种特殊的数据库罢了。