架构解耦

图 100: 含前端后台的架构

架构解耦

解耦是一件很有意思的过程，它也能反应架构的变迁。

从 MVC 与微服务

在我初识架构是什么的时候，我看到了 MVC 模式架构。这种模式是基于分层的结构，要理解起逻辑也很简单。这个模式如下图所示：

由我们的 Front controller 来处理由客户端（浏览器）发过来的请求，实际上这里的 Front controller 是 DispatcherServlet。DispatcherServlet 负责将请求派发到特定的

handler，接着交由对应的Controller来处理这个请求。依据请求的内容，Controller将创建相应 model。随后这个 model 将传到前端框架中渲染，最后再返回给浏览器。

但是这样的架构充满了太多的问题，如 view 与 controller 的紧密耦合、controller 粒度难以把控的问题等等。

Django MTV我使用 Django 差不多有四年了，主要是用在我的博客上。与 MVC 模式一对比，我发现 Django 在分层上还是很有鲜明特性的：

在 Django 中没有 Controller 的概念，Controller 做的事都交由 URL Dispatcher，

图 101: Spring MVC

图 102: Django MTV架构

Python 函数。然后这个函数就交由相应的 View 层来处理，而这个 View 层则是处理业务逻辑的地方。处理完后，Model 将传到 Template 层来处理。

对比如下图如示：

传统的 MVC 架构Django 架构

ModelModel(Data Access Logic)

ViewTemplate(Presentation Logic)

ViewView(Business Logic)

ControllerDjango itself

从上面的对比中，我们可以发现 Django 把 View 分层了。以 Django 对于 MVC 的解释来说，视图用来描述要展现给用户的数据。而在ROR等其他的MVC框架中，控制

器负责决定向用户展现哪些数据，而视图决定如何展现数据。

联想起我最近在学的 Scala 中的 Play 框架，我发现了其中诸多的相似之处：

虽然在Play中，也有Controller的概念。但是对于URL的处理先交给了Routes来处理，随后再交给 Controller 中的函数来处理。

不过与一般 MVC 架构的最大不同之处，怕是在于 Django 的 APP 架构。Django 中有一个名为 APP 的概念，它是实现某种功能的 Web 应用程序。如果我们要设计一个博

客系统的话，那么在这个项目中，Blogpost是一个APP、评论是一个APP、用户管理是一个 APP 等等。每个 APP 之中，都会有自己的 Model、View 和 Controller。其架构如

下图所示：

当我们需要创建一个新的功能的时候，我们只需要创建一个新的 APP 即可——为这个APP配置新的URL、创建新的Model以及新的View。如果功能上没有与原来的代码

重复的话，那么这就是一个独立的 APP，并且我们可以将这个 APP 的代码 Copy/Paste 到一个新的项目中，并且不需要做修改。

与一般的 MVC 架构相比，我们会发现我们细化了这些业务逻辑原来的三层结构，会随着 APP 的数量发生变化。如果我们有三个 APP 的话，那么我们相当于有 3* 三层，

但是他不是等于九层。这样做可以从代码上直接减少逻辑的思考，让我们可以更加集中注意力于业务实现，同时也利于我们后期维护。

虽是如此，后来我意识到了这样的架构并没有太多的先进之处。而这实际上是一个美好但是不现实的东西，因为我们还是使用同一个数据库。

图 103: Play 框架异步请求

图 104: Django APP 架构

这些服务之间互相协调、互相配合。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都应该有自己独立的数据库来存储数据。

图 105: 分散数据

Django 从某种意义上有点接近微服务的概念，只是实际上并没有。因为它没有实现 Play 框架的异步请求机制。抱句话来说，应用很容易就会在调用 JDBC、Streaming

API、HTTP 请求等一系列的请求中发生阻塞。

这些服务都是独立的，对于服务的请求也是独立的。使用微服务来构建的应用，不会因为一个服务的瘫痪让整个系统瘫痪。最后，这一个个的微服务将合并成这个系统。

图 106: Combined List