单体应用,垂直应用,SOA架构,SpringCloud微服务架构的特点及优缺点 应用架构的演变

应用架构的演变

单一应用架构

特点:

1. 所有功能集成在一个项目工程中
2. 所有的功能可以打一个war部署到服务器
3. 应用和数据库分开部署
4. 通过部署应用集群和数据库集群来提高系统的稳定性

优点:

• 开发简单
• 便于共享
• 易于测试
• 容易部署

缺点:

• 妨碍持续交付 即时间推移,单体应用会变大,构建和部署的时间也会相应地延长,不利于
• 不够灵活
• 受技术栈限制
• 可靠性差
• 伸缩性差 扩容时整体扩容,会造成资源浪费
• 技术债务 模块划分不清晰,功能添加耗时耗力,尤其人员更迭,更是麻烦

垂直应用架构

特点

1. 将一个大项目拆分成一个一个单体结构的项目
2. 项目与项目之间存在数据冗余,耦合性较大,冗余即存在大量的重复性代码
3. 项目之间的接口多为数据同步功能

优点

• 开发成本低
• 避免单体应用的无线扩大
• 系统拆分实现了流量分组,解决了并发问题
• 可以针对不同系统进行系统扩容,优化
• 方便水平扩展,负载均衡,容错率提高
• 不同的项目可以采用不同的技术
• 系统间相互独立

缺点:

• 系统之间相互调用,如果某个系统的端口或者ip地址发生改变,调用系统需要手动更新
• 相同的罗技代码不能复用,需要不断复制
• 系统性能扩展只能通过扩展集群结点,成本高,有瓶颈

SOA面向服务架构

特点

1. 基于soa的架构思想将重复公用的功能抽取我为组件,以服务的形式给个系统提供服务
2. 各项目和服务之间财通webService.RPC等方式通信
3. 使用ESB企业服务总线作为项目与服务之间通信的桥梁

优点:

• 将重复的功能抽取为服务,提高开发效率,提高系统的可用性,可维护性
• 可以针对不同服务的特点定制集群和优化方案
• 采用ESB减少系统中的接口耦合

缺点:

• 系统与服务的界限模糊，不利于开发及维护。
• 虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
• 抽取的服务的粒度过大，系统与服务之间耦合性高。
• 涉及多种中间件，对开发人员技术栈要求高。
• 服务关系复杂，运维、测试部署困难

微服务架构

特点

1. 将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
2. 微服务中每一个服务都对应唯一的业务能力，遵循单一原则。
3. 微服务之间采用 RESTful 等轻量协议传输。

优点

• 团队独立：每个服务都是一个独立的开发团队，这个小团队可以是 2 到 5 人的开发人员组成；
• 技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，使用什么技术什么语言开发，别人无需干涉；
• 前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口；
• 数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库；
• 服务拆分粒度更细，有利于资源重复利用，提高开发效率；
• 一个团队的新成员能够更快投入生产；
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值；
• 可以更加精准的制定每个服务的优化方案（比如扩展），提高系统可维护性；
• 适用于互联网时代，产品迭代周期更短

缺点:

• 微服务过多，服务治理成本高，不利于系统维护；
• 分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
• 微服务将原来的函数式调用改为服务调用，不管是用 rpc，还是 http rest 方式，都会增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛；
• 多服务运维难度，随着服务的增加，运维的压力也在增大；
• 测试的难度提升。服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。