PaaS服务之路漫谈(二)：Monolithic架构分析
PaaS服务之路漫谈(二)：Monolithic架构分析
网易杭州研究院·尧飘海
本文作于2015年2月
天下大势，分久必合，合久必分，社会历史的发展方向总有着惊人的相似。
把这种规律应用到软件应用架构的发展方向上，当生产力和生产关系到了不可调和的矛盾时，也将导致软件架构的演变。这样演变将会进一步推动软件的发展，同时也会带来很多问题，因此在不同的阶段，采用不同的架构适应业务发展是有一定道理的。步子太小，容易夹着蛋，步子太大，容易扯着蛋 。
从前文【PaaS服务之路漫谈（一）】的WEB应用技术的发展来看，WEB应用的服务架构模式的可以划分为Monolithic（整块架构）和MSA（微服务架构）。并且现在很大的中小应用还是使用Monolithic的架构模式，不同的架构模式应用在不同规模的应用中将产生不同的效果。
下面我们简单的对这两种架构进行分析。
Monolithic架构
随着移动应用的发展，现在的服务端程序需要提供不同的能力来支持包括桌面端、浏览器端及移动端等。早期的应用可通过CORBA，EJB等技术来实现，日前，考虑到各平台的兼容和简便性，大部分会通过暴露相关的服务接口或消息代理给第三方消费和实现消息交换。应用程序基本上通过分层或者组合的方式来架构，由不同的组件来完成相关职责
-
表现层，主要负责处理HTTP相关请求，然后返回不同的响应格式，包括HTML，JSON等
-
业务逻辑，即控制层，负责应用的逻辑处理
-
数据库层，负责模型层的数据存储和组织
这种架构的方式的实现方式如下：
在日常的软件开发过程中，无样采用什么样的软件模式，常常有这样的非功能性需求：
-
须有一完整的开发队伍保证应用的开发进度
-
新人希望能较快溶入队伍中，并能快速上手
-
应用希望能够容易的理解和修改
-
应用支持能够持续的部署
-
能较好实现扩展性和高可用性等非功能性需求
-
能够快速的利用新的技术的红利
在完成相关的功能开发和测试后，在上线时，会采用什么样的部署方式呢？对于JAVA应用大部分采用JAR或者WAR的方式来实现，对于其他的语言也基本采用打包整个目录的方式来完成部署，我们的自动部署平台系统中的大部分应用都是属于采用这种使用方式来实现部署上线。
采用这种架构模式的优势是：
-
易开发：整个应用能直接利用开发工具或IDE直接完成，除了一些依赖的服务，基本在能单机上完成；
-
测试简单：由于不涉及到多个系统的交互，因此对应的测试流程也会变得相对简单，单一的流程能完成相关的测试；
-
部署简单：通过一些部署的工具，甚至SHELL脚本即能完成整个应用的部署，其他的无非是一些规范化或定制化的东西；
-
易运维：通过复制多份的方式来实现模向扩展，负载均衡完成请求路由。
当然，随着系统的发展和扩大，Monolithic架构的一些问题也暴露出来了：
-
大量的代码经常会导致开发人员因为风险导致不敢轻易重构，同时还要完整的测试用例才能保证重构的完成；另外对新人来说，模块划分不清楚也会带来很多的挫折感，基本在一段时间内不敢对应用功能修改，情愿添加新增的方式来完成。而很大一部分的人都使用新增导致整个系统更复杂，最后很快就变得无法维护了
-
大量的代码会将导致CO代码的时间非常长，同时对应的IDE的编译时间和运行时间也变得不可预测，以前就碰到过同事的代码过长在紧张上线修改BUG时，导致ECLIPSE死掉而使得工作效率大大减少的问题；另外应用容器的启动时间也会因为应用代码的急增导致变长，不能快速的启动导致调试和测试的时间变长，影响应用的进度。同样在部署的过程中也会影响到用户的服务时间。
-
持续部署也是很困难的，如果应用要希望时常发布，这对运用运维也来也是一定的灾难，为了修改一个问题导致整个应用重新打包部署，编译时间打包又长，特别是在后端的应用修改的情况下还要进行前端代码的无功打包，对了运维人员的时间是个极大的浪费。如果应用里面包括定时任务等功能还可能对业务数据产生影响，导致运维的风险越来越高，加上开发人员对运维方式的抱怨，导致运维人员对发布越来抗拒，从而导致矛盾越来越严重。在同事使用自动部署平台的反馈中，有时候就听到开发人员和运维人员的相互指责或者抱怨。
-
扩展也是比较团难的，尽管大部门分的WEB应用能支持横向扩展，但是实际上，当应用规模扩展到了后端服务无法支撑时，比如后端单一数据库连接资源不够时，就无法扩展了。另外对其他的资源竞争也会导致无法真正的扩展，因为系统到一定规模时就有定会有热点数据，这个热点数据常会导致整个系统无法正常服务。系统的每个模块对资源的使用也是不同的，有些是CPU密集型，有些是IO密集型,因此，实际是不可扩展的，只是系统没有真的到达到相像中的那么大。
-
快速开发的障碍 整块应用的架构还将导致整个开发团队的相互依赖，一般来讲一个应用最后会发展成根据特定的功能划分成不同的工程师队伍，比如UI小组,交互小组，会员组，前端组等架构形式，这将使用得各工作的团队相互依赖，不能独立工程一个功能的修改会使得一系统的人员依赖和评估相关的风险，这也使得导致产品不能快速迭代。
-
技术债，此架构迫使开发人员严重依赖相关的技术，比如只能使用JAVA语言，甚至还些还依赖于特定的软件版本，就也会使得软件无法采用最新的版本，只能通过补丁加补丁的方式来完成，导致技术债越来越重。如果使用的软件版本不再提供维护，后面只能通过特定的人员或团队才能搞定或者采用整个应用重写的方式来实现，这在实际应用开发中是非常常见的，包括微软这样的大公司也避免不了这个问题，这将导致相关大的风险。
小结
上面我们大体根据实际应用中碰到的问题，对Monolithic架构的优势和问题进行了分析，但是本文并不是说Monolithic架构毫无用处，只是说明这种架构模式的适用场景。其实它在大部分的系统中还是使用这种模式完成的，并且还工作得很好，引用之前汪源引用GOOLGE大师的话，JUST WORK就好。
