Java应用系统的架构演变
系统架构演变
1）单体应用架构
web工程的所有模块（web层，service层，dao层）全部打包放到一个web容器中运行。
优点：
（1）架构简单，开发成本低，周期短，适合小型项目。
缺点：
（1）全部功能集成在一个工程中，对于大型项目不利于开发、拓展、维护。
（2）性能拓展只能通过扩展集群节点，成本高，有瓶颈。
（3）技术栈受限。
2）垂直应用架构
当访问量逐渐增加时，单一应用增加机器带来的加速度越来越小，将应用拆分成互不相干的多个应用，以提升效率。
优点：
（1）项目架构简单，开发成本低，周期短，小型项目的首选。
（2）通过垂直拆分，原先的单体应用不至于不限扩大。
（3）不同项目可以采用不同的技术。
缺点：
（1）全部功能集中到一个工程，对于大型项目不利于开发、拓展、维护。
（2）性能拓展只能通过拓展集群节点，成本高，有瓶颈。
3）分布式SOA架构
SOA(Service-Oriented Architecture)，即面向服务架构，通过将核心业务逻辑抽离成通用的服务组件进行分布式部署、组合和
使用，一个服务组件通常以独立形式的进程运行。
优点：
（1）抽取公共功能作为通用服务组件，提高开发效率。
（2）对不同服务进行集群化部署可以缓解系统压力。
（3）降低系统的耦合度。
缺点：
（1）抽取服务的粒度较大
（2）服务提供方和调用方的接口耦合度较高
4）微服务架构
微服务架构是在SOA机构上的一个升华，强调业务的彻底组件化和服务化，对业务系统进行更细粒度的逻辑拆分成多个独立开发运行的小应用。
优点：
（1）通过服务的原子化拆分，以及微服务的开发、打包部署，小团队的交付周期缩短，运维成本降低。
（2）微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。
缺点：
（1）服务过多，服务治理成本高，不利于系统维护。
（2）分布式开发成本高（容错，分布式事务等）。
SOA架构和微服务的区别：
功能 SOA 微服务
组件大小 大块业务逻辑 单独任务或小块业务逻辑
耦合 通常松耦合 总是松耦合
公司架构 任何类型 小型、专注于功能交叉团队
管理 着重中央管理 着重分散管理
目标 确保应用能够交互操作 执行新功能、快速拓展开发团队
