小公司做业务服务，需要聚焦到实际的业务上，尽快通过业务服务客户，给客户创建价值，公司才能生存下去。在技术上采用的Web应用架构具备以下特点：

• 主要由开源组件组装而成。这样既可以节省成本，也可以把时间聚焦到实际的业务当中，尽快实现业务。
• 需要功能丰富，能够支持业务快速开发。数据量虽然不一定大，但业务可能很多，关系型存储、非结构化存储、文件存储、关键字搜索、任务调度、消息中间件等一个都不能少，每个都需要用。

• 不需要支持大的“量”级。大多情况下不涉及大数据、高并发之类的，不能过度设计。
• 成本要低。不能采用耗费资源过大的组件，客户服务器预算有限，大多只能提供一台或者一个双机的服务器。

这里把这种架构成为“小架构”，这个“小”主要是指小型，其内涵是很丰富的，其核心是要支持业务快速开发，功能丰富且好用。

为了支持业务快速开发，仅仅把一系列开源组件组合还不够，还需要：

• 提供一个工程模版，把程序的启动、参数/返回值处理、异常处理等都规范好，可以直接开发业务。
• 把开源组件的配置、启动等封装起来，给业务提供能够之间使用的服务。比如消息中间件，业务注入一个服务就可以发消息，不需要关心下面用的到底是Kafka还是RocketMQ，也不关心它们是如何配置的，如何启动的。
• 提供一些通用的服务。有些是用开源软件不够易用的需要封装一下，有些没有开源软件提供能力的则自研一个。
• 提供一套规范，大家在这规范下可以快速开发出一致的、易维护的代码，也能够减少一些踩坑的情况。

这系列“小架构”的文章就主要是讲解如何搭建这种“小架构”的，以及了解相关原理。

在一家公司里，受限于人力有限和维护成本，从零建设架构的机会一般是很有限的，不太会每个项目都重头搞个不同的架构，这对公司的发展和维护是非常困难的。这意味着在一家公司里，能够接触到架构变更的机会是非常有限的，可能待很长时间都不一定有一次。架构的变动也是慎之又慎，毕竟底层的东西影响范围比较大。当时间长了，架构本身就会积累很多东西，也就更加难改变了。

自己在一家公司待的时间很长，经历过几次架构改动，架构有在逐步迭代完善。但还是有不少东西受限于历史原因和业务当时的限制而不得不做的妥协，留下了各种各样的“遗憾”。经常会有点小小的感慨：如果这个能一开始就做好一点就好了。所以面对这种感慨，自己萌生了有没有可能重头再写一个的想法。在工作上不好说什么时候能有这种机会，但在业余上则是可以尝试一下，把自己的一些心得实践一下，也把一些自己觉得“遗憾”的地方纠正一下。

做一件事情时间长的好处是这个事的全流程基本了解，里面有哪些坑和如何折中解决的也都了解。但也有个缺点，就是每次的迭代都是碎片化的，一个个知识就像一颗颗小珍珠一样散落到各个地方，总是感觉差一根绳子把这些零散的珍珠串接起来形成一个项链，也就是一个知识的体系。

借这个机会则可以把这些知识重新整理一下，把自己的一些思考记录下来，修正一些自己觉得不太好的地方，把自己之前了解的原理片段串联起来，从而形成一个小知识体系。

这种小架构，麻雀虽小却五脏俱全，要把里面的知识整理清楚，并不容易。一个东西好像是理解了，但如果要把它有条理的表达出来，难度就不在一个档次了。自己实际经历的不少东西是历史沉淀下来的，历史的局限也在里面，要把它的一些局限更换掉，既需要对局限的内容深入了解，也要钻研一些新的知识，才能把这些局限更换掉，这需要花不少时间。而在工作之外，时间本来就比较少，要把这个事情做成，挑战也比较大，需要自己给自己一股挤时间的劲，额外挤出足够的时间才有可能完成这个事情。把这个事列出来，也算是有一股监督的力量来推动一下自己。

笔者并没有研究过各个公司的架构，很多理解也仅是一家之言，所以这系列的文章有比较多的局限性，整理出来既可以供大家参考，也可以向大家学习。欢迎交流和指正。