原创转载请注明出处：http://agilestyle.iteye.com/blog/2358824
单块架构
MVC架构将应用在逻辑上分成了三层，但它不是物理上的分层。这也意味着，即便将应用架构分成了所谓的三层，经过开发团队对不同层的代码实现，经过Compile、Package、Deploy后，不考虑负载均衡以及水平扩展的情况，最终还是运行在同一台机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，通常称之为单块架构应用。
例如：
典型的单块架构应用，传统的JEE项目所构建的产品或者项目，通常以WAR包或者EAR包存在，当部署这类应用时，通常是将整个一个块作为一个整体，部署到同一个Web容器，如Tomcat或者Jetty中。当这类应用运行起来后，所有的功能也都运行在同一个进程中。
优势
劣势
- 维护成本增加
- 持续交付周期长
- 新人培养周期长
- 技术选型成本高
- 可扩展性差
- 构建全功能团队难
Note： 扩展分为垂直扩展和水平扩展
垂直扩展 如果应用程序的所有功能代码都运行在同一个Server上，会导致应用程序的扩展非常困难，如果扩展要求紧急，那么垂直扩展可能是最容易的（比如投行，证券等金融大鳄公司） 在大多数情况下，如果舍得砸钱上IBM的Server，Oracle的DB或者EMC的存储设备，不用改变一行代码，整个世界都会变得美好。但是，伴随着业务的增加，数据的增加，垂直扩展可能会变得一次比一次吃力，成为也会越来越高。
水平扩展 水平扩展通常的做法是建立一个集群，通过在集群中不断添加新Node，然后借助LB，将用户的请求按照LB算法（轮转法、散列法、最小连接法等）将请求分配到不同的Node上 但是，对于单块架构而言，由于所有程序代码都运行在Server的同一个进程中，会导致应用程序的水平扩展成本非常高。例如：如果应用程序某部分的功能是内存密集型的，需要缓存大量数据，而另外一部分功能是CPU密集型的，需要进行大量的运算，那么每次进行水平扩展，运行该应用的服务器都必须有足够的内存和强劲的CPU来满足需求（当然对大型互联网企业内存和CPU根本不是问题） 因此鉴于每台Server都要提供该应用系统所需要的各种资源，基础设施的整体花费可能非常高。另外，如果某些节点内部存在有状态的服务，比如用户登录信息等，会增加水平扩展的难度
Reference
微服务架构与实践 王磊 著