2016年6月8日星期三

Architect_016:把传统三层架构应用改造成微服务架构应用(摘录+整理)

1. 出租车调度软件
经过需求分析,会手动或使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目,它的六边形架构是模块化的 ,架构图如下:



应用核心是业务逻辑,由定义服务、域对象和事件的模块组成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件,以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑,但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如,许多Java应用会被打包为WAR格式,而另外一些Java应用会被打包成自包含的JAR格式,Rails和Node.js会被打包成层级目录。

2. 改造成微服务架构


每一个应用功能区都使用微服务完成,另外,Web应用会被拆分成一系列简单的Web应用(比如一个对乘客,一个对出租车驾驶员)。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。

每一个后台服务开放一个REST API,许多服务本身也采用了其它服务提供的API。比如,驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。

所有服务都是采用异步的,基于消息的通讯。

一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务,而是通过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务,可以通过 nginx 方便实现。

3. 微服务的三向扩展
应用基本可以用以上三个维度来表示:
  1. X轴  代表运行多个隐藏在负载均衡器之后的微服务实例(应用的多个副本)。
  2. Y轴  代表将应用分解为各个微服务。
  3. Z轴  代表将需求路由到相关服务。
以行程管理服务为例俩说,运行时,行程管理服务由多个服务实例构成。每一个服务实例都运行在一个Docker 容器中。服务实例的前端是一层诸如nginx的负载均衡器,负责在各个实例间分发请求。负载均衡器也同时处理其它请求,例如缓存、权限控制、API统计和监控。

不像传统多个服务共享一个数据库,微服务架构每个服务都有自己的数据库这种架构需要这种松耦合。
每种服务可以用更适合自己的数据库类型,也被称作多语言一致性架构。比如,驾驶员管理(发现哪个驾驶员更靠近乘客),必须使用支持地理信息查询的数据库。

下图展示了应用数据库架构:



参考文献:
1. http://nginx.com/blog/introduction-to-microservices/
2. http://dockone.io/article/394

没有评论: