1.1.2 集群及垂直化

假设在1.1.1节中提到的商城系统是某个创业公司早期的产品，我们知道技术只是业务的一个载体，它使得用户通过网页就能轻松实现线上购物，所以最终的核心还是产品的长期运营。作为公司，肯定希望这个产品被越来越多的人使用，这样才能创造更大的价值。如果这个希望变成了现实，那么对于整个技术架构来说，可能会面临以下挑战：

• 用户量越来越大，网站的访问量不断增大，导致后端服务器的负载越来越高。

• 用户量大了，产品需要满足不同用户的需求来留住用户，使得业务场景越来越多并且越来越复杂。

当服务器的负载越来越高的时候，如果不进行任何处理，用户在网站上操作的响应会越来越慢，甚至出现无法访问的情况，对于非常注重用户体验的互联网产品来说，这是无法容忍的。

业务场景越多越复杂，意味着war包中的代码量会持续上升，并且各个业务代码之间的耦合度也会越来越高，后期的代码维护和版本发布涉及的测试和上线，也会很困难。举个最简单的例子，当你需要在库存模块里面添加一个方法时，带来的影响是需要把整个商城重新测试和部署，而当一个war包有几GB的大小时，部署的过程也是相当痛苦的。

因此，我们可以从两个方面进行优化：

（1）通过横向增加服务器，把单台机器变成多台机器的集群。

（2）按照业务的垂直领域进行拆分，减少业务的耦合度，以及降低单个war包带来的伸缩性困难问题。

如图1-2所示，我们把商城系统按照业务维度进行了垂直拆分：用户子系统、库存子系统、商品子系统，每个子系统由不同的业务团队负责维护并且独立部署。同时，我们针对Tomcat服务器进行了集群部署，也就是把多台Tomcat服务器通过网络进行连接组合，形成一个整体对外提供服务。这样做的好处是能够在改变应用本身的前提下，通过增加服务器来进行水平扩容从而提升整个系统的吞吐量。

需要注意的是，图1-2中针对数据库进行了垂直分库，主要是考虑到Tomcat服务器能够承载的流量大了之后，如果流量都传导到数据库上，会给数据库造成比较大的压力。

图1-2 集群及垂直化之后的架构

总的来说，数据库层面的拆分思想和业务系统的拆分思想是一样的，都是采用分而治之的思想。