设计匠艺 | 小即是美之二

小的益处还有一点，它可以使得我们在架构决策或技术选型时，可以变得更加从容。

譬如说，因为某些原因我们需要将整个企业系统从WebLogic上迁移到JBoss上，无疑，这是一个艰难的决定。即使在决策确定，要完成整个迁移也将是一个漫长的过程。如果系统是基于Micro Service的架构风格进行构建，每个服务根据各自情形选择自己的技术栈。倘若需要对某些服务进行技术栈迁移，相信这个问题不再变得棘手。——大象可以轻盈地跳舞，但付出的努力会百倍于一只敏捷的狐狸。

如今，Java已经发展到Java 8，引入的Lambda表达式等多个特性如此鲜嫩，让人垂涎不已。然而据我所知，国内多数企业的Java项目仍然停滞在JDK 6裹足不前。是JDK 8不够好吗？非也。盖因为求稳的他们仍然心存顾虑。即使Oracle号称这种JDK的迁移多么的平滑，多么的稳健，多数企业仍然不敢轻易做出迁移的决定。若因为迁移而带来未知的缺陷，可谓得不偿失。既然现在项目运行良好，何必冒此风险。

于是，我们这个行业因为系统的庞大而变得守旧老成，亦步亦趋。并非大家没有冒险的精神，实则是庞大的项目难以灵活地改变方向。倘若只是更新系统中的某一个库或框架，形势就截然不同了。记得在没有lambda的时代，当我们让客户看到了Guava的好处时，要引入Guava就轻而易举，真如顺水推舟了。

当我们发现某些功能具备独立和专注的特征时，都是可能做出小系统的机会。这些小系统并不一定是子系统或模块，它还可以是一个独立的应用或服务。

例如在一个税务系统中，需要生成复杂的税务报表。它的整个逻辑是相对独立的，不管是报表的动态生成，格式的转换，数据的查询以及流的处理和PDF文档的生成，都与系统其他部分关联不大。唯一可能与系统存在紧密关联的是数据库。但为了解决高峰期的性能问题，我们可以建立单独的数据提取器，又或引入流处理，定期将数据提取出来，放入内存数据库中。将这样相对独立的功能做成服务，就能够独立演化，并有效支持服务请求的可伸缩。这样的小型服务可以更灵活地应对变化。当我们发现内存数据库不能满足大量请求时，也可以轻而易举地将其迁移到NoSQL上，并根据数据的属性例如按照地域进行分区，支持水平扩展。

若要保证系统的小，我们还可以尝试使用脚本。在开发软件系统时，可以使用一些脚本语言来开发一些小工具，以应对灵活的需求变化，消除重复代码，实现某些步骤的自动化。例如用Groovy编写一些函数，用Ruby编写代码生成工具，又或者使用Gradle、SBT实现系统的自动部署，启动服务器等脚本。脚本语言具有很好的灵活性，而动态语言的特性也使得我们能够编写出短小精悍的超级小工具，甚至可以作为系统模块之间的粘合剂，如机器齿轮上的润滑油一般，让整个系统充满活力。

Russ Miles认为：团队的开发速度经常因编写代码体积和复杂度的增长而放缓。他认为组件结构在简化架构方面非常重要，并提出了Life-Preserver模型。这是一个环形结构，所有的基础设施软件都在环上处理集成，而核心业务组件在环内加入业务价值。这种模型的核心是利用事件来简化架构。

使用事件的一个显著特点是解耦，使得事件的发布者与订阅者都可以独立演化，也可以自由增加事件的订阅者数量。我们可以将事件的发布者与订阅者设计为独立的小程序，就像Unix系统中那些小工具一样，通过管道建立关联。这样的设计思想称之为EDA（Event Driven Architecture），我希望在以后的文章对此进行深入介绍。