在日常的软件开发当中，我们一般都是采用了分层的方式来架构系统，但是为什么我们需要分层进行架构呢？在此之前，我觉得需要搞明白两个概念，什么是软件的伸缩性，什么是性能。
首先，什么是软件的伸缩性（Scalability）？我们都知道设计良好的系统可以应对不断增加的系统访问量，但是我们如何能在系统用户增多的时候，来提高系统的吞吐量呢？这就是伸缩性之魅力所在。
伸缩性可以有两个方面，垂直伸缩性和水平伸缩性，垂直伸缩性是通过在同一个业务单元中增加资源来提高系统的吞吐量，比如增加服务器cpu的数量，增加服务器的内存等。水平伸缩性是通过增加多个业务单元资源，使得所有的业务单元逻辑上就像是一个单元一样。比如EJB分布式组件模型，集群配置等都属于此种方式。
下面我说一下，我对性能的理解，我们在日常的开发当中，当说到性能的时候，一般都会首先想到系统有多“快”，我想说的就是性能还涉及到另一个方面，那就是系统有“多少”，也就是说系统的吞吐量。我们在考虑性能的时候，一般都会考虑到这两方面。
理解了伸缩性和性能这两个概念以后，我们来看看系统为什么需要分层架构。
首先采用分层架构的好处，我想大家肯定都会普遍接受的是，系统分层有利于系统的维护，系统的扩展。这其实就是系统的可维护性和可扩展性。
其次，我围绕伸缩性以及性能来说一下，为什么需要分层架构。比如在目前的J2EE系统开发当中，我们普遍采用了分层构架的方式，一般分为表现层，业务层和持久层，当然了我们还可以对各层进行进一步的划分，但是层次划分也不能太细，具体项目要具体对待，原因下面讨论。我们想想，采用分层以后会带来什么不好的地方？想这个问题，我们可以先反过来想一下，不采用分层有什么好处，这当然是每个业务处理速度会更快，因为层与层之间通信会引来额外的开销，所以采用分层后，给我们软件系统带来的就是每个业务处理开销会变大。
好了，既然采用分层会带来额外的开销，那么我们为什么还要进行分层呢？这就涉及到了伸缩性和性能的问题。
如果不采用分层的话，系统的扩展和伸缩也主要靠垂直伸缩，但是垂直伸缩是有限度的，随着系统规模的扩大，垂直伸缩带来的代价也将变得非常昂贵。当采用了分层以后，虽然带来了层与层之间的通信开销（这得益于计算机硬件的飞快发展，如果计算机硬件的发展水平不足以抵消分层以后带来的额外的开销，那么分层架构也会有一个巨大的问号，所以从某种程度上来说，分层架构也利用了一点垂直伸缩性），但是它有利于层的水平伸缩性，并且各个层都可以进行独立的伸缩而不会影响到其它的层，比如EJB分布式组件模型以及目前采用的分成架构的方式就有利于水平伸缩性，
对于性能方面，我上面也说了，性能存在两个方面，一是“快”，二是“多少”，采用分层架构，当然会影响到性能快的方面，因为层次之间通信会带来额外的开销，但是采用了分层架构后，我们的软件系统可以更容易变大(“多少”的问题)，也就是说当系统要应对更大的访问量的时候，我们可以通过增加多个业务单元资源（此时的多个业务单元逻辑上看起来就像一个逻辑单元，这对外界是透明的）来增加系统吞吐量。所以对于那些实时性比较高的系统，层的划分不应该太细，太细必然带来实时性的减低，而对于实时性不高，而需要高度的伸缩性的系统，我们可以通过引入不同的层来达到系统水平伸缩的目的。
以上是有关伸缩性和性能，以及它们与分层架构之间的联系，下面我再说一下另外一个问题，这就是Amdahl law(阿姆达尔定律),这个定理主要说明了系统中串行部分对系统速度提升的影响，假设程序中串行部分占a%的比例，那么程序最多提升1/a%的速度。我从这个定律也看出了，软件垂直伸缩的局限性，因为无论增加多少个cpu，如果程序中有串行化的部分，那么程序的速度的提升是有一个极限的，是不能靠增加硬件来无限度的增强系统性能的。所以对于我们软件工程师来说，我们更加需要关注系统的水平伸缩性。
首先，什么是软件的伸缩性（Scalability）？我们都知道设计良好的系统可以应对不断增加的系统访问量，但是我们如何能在系统用户增多的时候，来提高系统的吞吐量呢？这就是伸缩性之魅力所在。
伸缩性可以有两个方面，垂直伸缩性和水平伸缩性，垂直伸缩性是通过在同一个业务单元中增加资源来提高系统的吞吐量，比如增加服务器cpu的数量，增加服务器的内存等。水平伸缩性是通过增加多个业务单元资源，使得所有的业务单元逻辑上就像是一个单元一样。比如EJB分布式组件模型，集群配置等都属于此种方式。
下面我说一下，我对性能的理解，我们在日常的开发当中，当说到性能的时候，一般都会首先想到系统有多“快”，我想说的就是性能还涉及到另一个方面，那就是系统有“多少”，也就是说系统的吞吐量。我们在考虑性能的时候，一般都会考虑到这两方面。
理解了伸缩性和性能这两个概念以后，我们来看看系统为什么需要分层架构。
首先采用分层架构的好处，我想大家肯定都会普遍接受的是，系统分层有利于系统的维护，系统的扩展。这其实就是系统的可维护性和可扩展性。
其次，我围绕伸缩性以及性能来说一下，为什么需要分层架构。比如在目前的J2EE系统开发当中，我们普遍采用了分层构架的方式，一般分为表现层，业务层和持久层，当然了我们还可以对各层进行进一步的划分，但是层次划分也不能太细，具体项目要具体对待，原因下面讨论。我们想想，采用分层以后会带来什么不好的地方？想这个问题，我们可以先反过来想一下，不采用分层有什么好处，这当然是每个业务处理速度会更快，因为层与层之间通信会引来额外的开销，所以采用分层后，给我们软件系统带来的就是每个业务处理开销会变大。
好了，既然采用分层会带来额外的开销，那么我们为什么还要进行分层呢？这就涉及到了伸缩性和性能的问题。
如果不采用分层的话，系统的扩展和伸缩也主要靠垂直伸缩，但是垂直伸缩是有限度的，随着系统规模的扩大，垂直伸缩带来的代价也将变得非常昂贵。当采用了分层以后，虽然带来了层与层之间的通信开销（这得益于计算机硬件的飞快发展，如果计算机硬件的发展水平不足以抵消分层以后带来的额外的开销，那么分层架构也会有一个巨大的问号，所以从某种程度上来说，分层架构也利用了一点垂直伸缩性），但是它有利于层的水平伸缩性，并且各个层都可以进行独立的伸缩而不会影响到其它的层，比如EJB分布式组件模型以及目前采用的分成架构的方式就有利于水平伸缩性，
对于性能方面，我上面也说了，性能存在两个方面，一是“快”，二是“多少”，采用分层架构，当然会影响到性能快的方面，因为层次之间通信会带来额外的开销，但是采用了分层架构后，我们的软件系统可以更容易变大(“多少”的问题)，也就是说当系统要应对更大的访问量的时候，我们可以通过增加多个业务单元资源（此时的多个业务单元逻辑上看起来就像一个逻辑单元，这对外界是透明的）来增加系统吞吐量。所以对于那些实时性比较高的系统，层的划分不应该太细，太细必然带来实时性的减低，而对于实时性不高，而需要高度的伸缩性的系统，我们可以通过引入不同的层来达到系统水平伸缩的目的。
以上是有关伸缩性和性能，以及它们与分层架构之间的联系，下面我再说一下另外一个问题，这就是Amdahl law(阿姆达尔定律),这个定理主要说明了系统中串行部分对系统速度提升的影响，假设程序中串行部分占a%的比例，那么程序最多提升1/a%的速度。我从这个定律也看出了，软件垂直伸缩的局限性，因为无论增加多少个cpu，如果程序中有串行化的部分，那么程序的速度的提升是有一个极限的，是不能靠增加硬件来无限度的增强系统性能的。所以对于我们软件工程师来说，我们更加需要关注系统的水平伸缩性。
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/2534/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
手把手教你使用数字温度传感器DS18B20
TCP TIME_WAIT状态（2MSL)评论列表
