单一应用架构与分布式架构的区别

/ 分布式 / 204浏览

单一应用架构

1.应用内容
  一个服务器端的企业级应用,它必须支持多种不同的客户端,包括Web浏览器、手机浏览器、以及手机APP。这个应用也许还会暴露一个API,给第三方程序去调用。它也许还会与其他应用集成,通过web services或消息中间件。 这个应用通过运行业务逻辑、访问数据库、与别的系统交换消息、然后返回一个HTML/JSON/XML响应的方式来处理HTTP或者消息请求。也就是说把所有的功能都放在一个项目工程里,部署在一台服务器上。

2.解决方案
  比如我们一个互联网金融网站,我们创建一个工程叫p2p,这个工程里面包含所有的功能:注册、登录、投资、充值、提现、合同、红包、消息等等。
  这时需要构建一个单一应用架构的应用,比如一个单一的Java War文件,然后在Tomcat上运行的Java web应用。

3.方案结果

⚠ 但是,一旦这个应用变得庞大,团队规模变大,这种解决方案的缺点变得越来越重大:

分布式应用架构

1.应用内容
  同单一应用架构的内容。

2.解决方案
  创建一个应用架构,使得这个应用的结构是一系列松耦合、互相合作的服务(services)。把所有的程序、功能拆分成不同的子系统,部署在多台不同的服务器上,这些子系统相互协作共同对外提供服务,而对用户而言他并不知道后台是多个子系统和多台服务器在提供服务,在使用上和集中式系统一样。

  服务之间用同步协议比如HTTP/REST或者异步协议比如AMQP来进行通信。 每个服务有自己独立的数据库,从而与别的服务解耦。服务之间的数据一致性通过使用事件驱动架构来维护。如下图: alt

3.方案结果
  优势:

缺陷:

4.问题
⭐什么时候适合使用分布式架构❓
 当访问量越来越大,单一的单服务器已不能满足需要,我们需要通过不断添加服务器的方式来应对越来越大的访问量,但是通过不断添加服务器的方式带来的速度提升也越来越小,此时我们就需要拆分我们的应用,拆分成几个独立的不相干的应用,部署在不同的服务器上,以提升服务的能力。
⭐如何把应用拆解成多个服务❓

⭐如何保持数据一致性❓
 为了保证松耦合,每个service有它自己的数据库。维护service之间的数据一致性是一个挑战,因为二阶段提交事务/分布式事务并不是很多应用的一个选项。相反的,一个应用必须使用事件驱动架构。一个服务在它的数据变化时,会发布一个事件。别的服务消费这个事件,然后更新自己的数据。有很多种可靠的数据更新和事件发布的方法,包括事件源和事务日志跟踪。

⭐如何实现查询❓
 另一个挑战是实现需要从多个服务那里获取数据的查询。一个普遍的做法是使用命令查询职责分离,维护一个或多个view,它们通过订阅事件流的方式一直保持最新,事件流中的事件是别的service在数据变化时发布的。