再读《架构整洁之道》

前一阵子读了 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 大叔举的例子何其相似!搜索引擎,无非就是一种特殊的数据库罢了。

你可能感兴趣的:(读后感,架构)