可伸缩性的艺术（2）

本来翻译出来想放在技术部知识库上的，担心太烂被人拍死，放在javaeye吧，欢迎斧正：）

 

原文地址http://www.hfadeel.com/Blog/?p=122

可伸缩性的艺术（2）

我打算写两至三篇关于可伸缩性的文章。其中第一篇文章叫做‘可伸缩性原则’——介绍可伸缩性的概念及其原则，接下来我会介绍可伸缩性模式、相关反模式以及一些指南。我们现在开始吧！

Go to : 第一篇- 可伸缩性原则（http://www.hfadeel.com/Blog/?p=120）
构件可伸缩性软件系统之指南：

1.降低处理时间：

在任何一本关于优化的书中，都会提到代码优化——采用更好的算法、代码、设计或者策略去降低系统的处理时间。同样的，降低请求的处理时间是最重要的可伸缩性指南之一。增加应用系统的数量确实可以减少每个独立工作单元处理的时间。比如说：降低一个用户的请求时间意味着你可以在相同的时间内处理更多的用户请求，但是如何做到呢，请看下面的例子。

   

    * 缓存：如果数据和代码没有配置在一起，那就缓存数据以减少一次又一次获取数据时的开销。
    * 并行化：通过将问题分解，并同时处理分解后的独立步骤，我们可以减少每个工作单元处理的时间。
    * 远程处理：减少访问远程服务所花费的时间，比如，可以使接口的粒度更粗一些。我们应该铭记：远程VS本地是一个很明显的设计的结果，而考虑分布式计算的第一准则是不要分散你的对象。
    * 配置化：通过数据和代码的配置，减少任何获取数据的开销。
    * 池：利用池思想减少任何贵重资源的开销。

 

当我们需要时，我们总是尽量引入抽象和层的概念使那些以往的技术更加容易，但是软件开发者总是在最高级的抽象和最低级的抽象之间迷茫。没错，这些可以可以帮助我们解耦合，但是他们往往增加了软件的复杂度，影响了系统的性能，特别是在每一层做数据视图转换的时候。因此，如果我们降低这些抽象性 ，并且使用尽量少的层，那么处理时间就会达到最小化。除此之外，我们应该明白运行时服务可能成为我们系统的瓶颈，除非系统间存在特定的服务级别的约定。

我想说的是：你无需实现这些所有的关键点，因为不存在一个固定的模式。

 

2- 分割:

降低处理时间涉及到其他的概念，比如我刚才说的代码优化、分割、异步。

你可以通过功能分割你的系统（关联属于相同功能的部分，不同功能的部分分割出去）。更进一步说，越是解耦合 不相关的功能点，系统的可伸缩性便会越高, 这样你可以独立的扩展这些相互独立的功能。比如，支持多台web服务器的数据库服务器，当它出现瓶颈时，你必须采取办法缓解，其中一个方法是分割策略。简单来说，就是将整个架构拆分的很多可以管理的模块。将一个元素分割成多个小模块可以获得很好的可伸缩性，这也是很多大型网站比如Amazon、Facebook使用的。所以，分割是一个好的解决方案。

 

3.异步处理
在你将系统分割之后，可伸缩性的下一个关键步骤是充分利用异步。如果组件X通过同步调用组件Z，那么组件X和组件Z就仅仅的耦合在一起了，而且相互耦合的系统的可伸缩性是绑定在一起的——如果打算扩展组件X，必须先扩展组件Z，而且在可用性方面也存在同样的问题。回到刚才的逻辑，如果X->Z，那么!Z->!X,换句话说，如果x不起作用了，那么Z也就不起作用了。相反的，如果组件Z和组件X是异步调用的，不管采用队列、组播消息、批处理任务，或者其他的方式，每个组件都可以独立的扩展。除此之外，组件Z和组件X的可用性也是相互独立的——不管B是否down掉，A都可以继续运行。

这一原则也可以应用于基础设施，比如SEDA（阶段性事件驱动架构）这种技术在单独的组件内部使用异步调用，最后却可以保持原有编程模型的可阅读性。在组件之间，这一原则也是一样的——尽可能的避免同步调用产生的耦合，除此，各个组件之间没有任何直接调用。在各个层次将过程分解成若干阶段，通过异步调用相互关联，这是可伸缩性的至关重要的一步！

 

4.关于并发的可伸缩性
和前面并行化的研究一样，我认为可伸缩性问题就是并发问题，并发问题就是并行化问题:)。通过并行化，尤其是异步流程去降低处理时间都是非常不错的主意。但是要切记，并行化不像异步那么容易。我会给出一些如何通过并行化降低处理时间的小建议：
 

   * 如果你确实需要使用锁（比如对象锁，数据库锁等），尽可能的减少锁定的时间。
    * 尽量最小化共享资源的连接，并且尽量不要去连接一些临界资源（比如：异步调度）
    * 任何需要并发的设计需要慎之又慎，因为任何安全共享的资源都可能成为潜在的可伸缩性的瓶颈所在