0%

构架模型概述

这次的QCon去打了个酱油,发现现在微服务框架已经变成最火的概念了。有人说微服务其实就是SOA的包装,其实我觉得并不能完全这么说。SOA和微服务的区别在于粒度更细,更容易,但是话说回来,“细”,“容易”本身也不是用来区分的。QCon回来找了一本书《Software Architecture Patterns》看了一下,说的还不错。这是一本比较轻量的书,相比于之前的一本圣经基本的书《Pattern-oriented Software Architecture》,实在是太轻量了。下面就简单谈一下书中提到的几种软件建构。

Layered Architecture

这种架构是最古老的架构,一般最早想到的架构就是这种架构,在早起的Java EE项目(比如传统软件公司)中广泛使用。可以用下面的图来表示。简单来说就是整体按功能分成多个层级(展现层、业务逻辑层、持久化层、DB),层级之间再交互,理论上各个层级之间松耦合,但是实际实现中经常会出现紧耦合的情况。正常的request是通过一个一个层级最后到达DB。

评价:

  • Overall Agility: Low.
  • Ease of Deployment: Low. 这种架构可以把最后的程序看成一个二进制文件,部署的话就是服务器上的二进制文件替换掉。这种部署方式不容易的地方在于对于每一个小的改动都需要重新编译整个大项目,非常不灵活。
  • Testability: High.
  • Performance: Low.
  • Scalability: Low.
  • Ease of Development: Easy.

Event-Driven Architecture

事件驱动架构模型通常用于分布式的异步系统中,比如说服务器模型。这种架构又可以分两个种类:Mediator 和 Broker。Mediator如下图所示。

上图中的Mediator主要包括四个部分:event queue, event mediator, event channel 和 event processor。其中 queue 主要负责接收原始的事件,现在可以实现这种功能的包括各种消息队列组件,比如Kafka, ZMQ 等;mediator 负责调度event到不同的channel;最后不同的channel对应不同的processor。以服务器为例,用户request到达服务器之后,我们可以选择多种处理方式,异步的处理方式就是使用一个主进程负责接收所有的用户请求,但是并不处理,而是放到消息队列中。然后起多个线程去异步处理消息队列中的事件。关于这个异步处理是用线程还是进程,我觉得都可以。

Broker模型图如下所示。

Broker和Mediator的区别在于对于原始的event不进入mediator而是直接送到first processor,再加工之后送到second processor。

评价:

  • Overall Agility: High.
  • Easy of Deployment: High. 因为这种架构是天然松耦合的。Mediator和Broker比较起来,Broker又更容易一些,因为Mediator中mediator导致完全解耦合是不可能的。
  • Testability: Low.
  • Performance: High.
  • Scalability: High.
  • Ease of Development: Low.

Microkernel Architecture

这种架构模式是把核心系统发布出来,然后其他功能通过各种插件实现。一图以蔽之。

评价:

  • Overall Agility: High.
  • Easy of Deployment: High.
  • Testability: High.
  • Performance: High.
  • Scalability: High.
  • Ease of Development: Low.

Microservice Architecture

终于到微服务架构了。微服务架构简单来说就是按功能把整个系统拆解成尽量小的组件,然后每个组件做成一个单独的服务。这样系统就可以针对每一个组件进行单独的开发,部署和维护。这样带来的一个好处是开发人员只需要专注于自己的部分就可以了。

当然微服务框架也是有问题的。套用前东家CTO的话,微服务架构有一个好处,就是承诺了一个愿景,考虑围绕业务领域组建来创建应用,这些应用可独立进行开发、管理和迭代,从而使管理和服务功能的交付变得更加容易。但是我个人认为,这个概念很简单,但要把这一点做好并不容易。微服务架构特性决定了每个微服务实现的功能要相对独立,同时不能太复杂,复杂的应用要多个微服务协调产生。那么如何在保持微服务敏捷特性的同时,高效地组建复杂应用,就是最关键的问题。尤其是对于业务领域相对复杂的公司来说,客户都是大企业,应用很复杂,这其实对架构师的水平是更高的挑战。

评价:

  • Overall Agility: High.
  • Ease of Deployment: High.
  • Tesability: High.
  • Performance: Low. 因为整个系统架构是一个分布式的,比如消息通讯就会导致性能不够好。
  • Scalability: High.
  • Ease of Development: High.

Space-based Architecture

讲道理,这个有点没太看懂,就先不写了。