系统架构

1、单一应用架构

1、模块之间耦合度太高，其中一个升级其他都得升级

2、开发困难，各个团队开发最后都要整合一起

3、系统的扩展性差

2、垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆封成几个互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架（MVC）是关键。

3、系统拆分

拆分理由：

（1）应用间耦合度严重。系统内各个应用之间不通，同样一个功能在各个应用中都有实现，后果就是改一处功能，需要同时改系统中的所有应用。这种情况多存在于历史较长的系统，因各种原因，系统内的各个应用都形成了自己业务小系统。

（2）业务扩展性差。数据模型从设计之初就支持某一类业务，来了新类型的业务后又得重新写代码实现，结果就是项目延期，大大影响业务的接入速度。

（3）代码老旧，难以维护。各种随意的if...else、写死逻辑散落在应用的各个角落，处处是坑，开发维护起来战战兢兢。

（4）系统扩展性差。系统支撑现有业务已是颤颤巍巍，不论是应用还是DB都已经无法承受业务快速发展带来的压力。

拆分前准备什么：

（1）把握业务复杂度。

（2）高内聚、低耦合、单一原则

（3）确定拆分后的目标

（4）确定当前要拆分的架构状态、代码情况、依赖状况、并推演可能的各种异常

4、分布式架构

将不同的业务拆分为独立的服务单元。

（1）单一应用架构中，业务耦合度高，业务上有交集。而且修改一个功能其他功能都得修改。

（2）垂直应用架构中，各个系统之间比如都有人员列表信息，每个系统都得写一遍，业务间不能进行复用。

（3）分布式应用架构中，对于每个系统（薪资管理系统，人力资源系统，ERP系统），都能够使用独立的业务模块（人员服务、薪水、考勤）。在后期部署的过程中，会把系统打包成war包，把服务打包成war包。

但是，系统是不能够直接去调用服务的，因为系统war包属于系统级别，服务war包也属于系统级别，系统是不能直接去调用系统的。这个过程存在的问题是RPC（远程调用）。解决这个问题的办法是使用阿里巴巴的服务中间件，如dubbo,或dubbox。