软件架构之可伸缩性

      在软件架构中，为了保证应用的可扩展性和灵活性，往往会牺牲一定的性能。这里的性能主要指一个工作单元、功能单元的资源消耗情况。在工作单元增加的情况下，如何保证资源的消耗不会出现非线性的增长，这是衡量软件架构是否具有可伸缩性的指标。设计的可伸缩性就是保障在工作单元增加的情况下，资源的消耗随负载线性增加。以下是系统实现可伸缩性的最佳实践：

       一、按功能垂直切分

       没有切分就没有可伸缩性，按功能垂直切分把不相关的功能完全隔离，通过很小的接口实现松散耦合。这样每一个独立的功能都能够独立变化，独立伸缩，变化和伸缩影响的范围在功能模块内部。

       在编码层面，通过jar文件，包，类，Bundle实现功能分割和抽象。

       在应用层面，一个大型应用分成若干个小的应用独立部署，如购物网站的交易、商品、账户等分开部署，形成不同的应用。

       在数据库层面，把不同功能的数据存放在不同的数据库中，保持相对独立。如一个库存放交易数据，一个库存放商品数据等。

       二、水平切分

       在完成按功能垂直切分之后，随着负载的增加，每一个功能应用会超出单一系统的能力，需要进行水平切分，把相同的应用部署在不同的物理系统上。

       在应用层面，要实现水平切分，可以随意将应用部署在不同的物理服务器上，就要求应用没有状态。在大多数web应用中，应用都是没有状态的，水平分割是已经轻而易举的事情。为了保证负载均衡，需要做好负载均衡策略，如（硬件负载均衡器，软体负载等）。根据不同的应用场景和资源情况，可以选取不同的负载均衡策略，如：随机、轮询、加权等。

       在数据库层面，由于数据库天然是有状态的，因此数据库水平分割很具有挑战性。分割策略有2N策略，N/n策略，Hash(N)策略，查找表等。在选择分割策略时，需要考虑join的复杂性和再分割的可实现性。

       三、避免分布式事务

       在进行垂直和水平切分之后的数据，如何保证不同功能在同一事务的要求。例如，把购物系统拆分成交易中心、账户中心、商品中心之后，要完成交易，需要更新账户数据、商品中心的数据；如果一个步骤失败，则交易不能完成。但为了保证一致性，性能、响应时间都会受到事务协调成本的影响。实际上，完成一次交易，交易中心是核心功能，可以其它非核心功能，可以放宽对跨系统事务的保证。

       在淘宝、ebay，都没有使用分布式事务，都优先保证功能基本可用。避免使用分布式事务造成的不一致性并非没有办法弥补。可以通过数据核对、集中结算、任务等方式保持最终的一致性。

       四、异步策略

       实现系统架构可伸缩性的另一重要方式是积极使用异步策略。异步策略把一个过程分成若干个阶段，然后异步地连接起来，让一个过程涉及到得各个应用处于一种松耦合的状态。比如一个过程：完成交易、扣款、更新商品、发短信通知，优先保证完成交易，给用户已及时的响应，再以异步的方式去扣款、更新商品、发短信通知等。异步策略保证了在扣款模块档掉了，其它模块任然可用。

       五、虚拟化

       虚拟化、抽象化在软件设计中无处不在，很多设计上的问题都是通过增加一个间接层来解决。在数据库和应用中进行了分割之后，为各种分割增加额外的虚拟层次就尤为重要。虚拟化在系统内部实现分割之后，保证系统对外以统一的形式呈现，让内部分割对使用者透明。