前段时间因项目需要及个人兴趣着手开发中间件平台，代号“乐高”，简介性的文字就忽略了，直接上PPT截图：

Android 开发中间件是什么_中间件

Android 开发中间件是什么_事件总线_02

   

乐高已完成1.0版本，稳定性、性能等方面都不错，目前已有项目接入这个平台，当然这不是本文的重点，下面要谈谈这期下来的问题总结。 1.0版本总体架构可以用下图表示：

Android 开发中间件是什么_应用开发_03

 

其特点如下：

  1. 两种通讯方式：走事件总线及WS；
  2. 所有通讯都要经过RBAC组件做权限过滤；
  3. 上层应用与组件无差别，应用直接接入到平台，一个应用可成为别一个应用的组件。

而它的问题主要由第3点引发，当初把应用以组件的格式封装是为了实现应用层的复用，类似OSGi，所有东西都运行在一个平台上，但这会导致：


  1. 平台不稳定，一般而言中间件与应用开发分属不同团队，应用团队开发的应用无法保证稳定，“一颗老鼠屎坏了一锅粥”，虽然技术做到了一定的隔离（比如不同组件运行在不同JVM中）但毕竟应用已在平台内了，如果它要使坏就可以随意获取各类资源（跳过RBAC组件）；
  2. 因为应用在平台内，它可以发起事件请求，而事件请求要求很高效（平台内会有很密集的事件流），但为权限校验所有通讯都要经过RBAC组件过滤，一次请求可能会有N个子请求（如某个计算任务，它可能会由调度器组件触发，经过持久化组件获取任务信息，再调用计算组件计算，计算前要由数据传输组件获取数据……）如每一个都过滤一遍那对资源的消耗是很可观的；
  3. 应用开发不够自由，因为要给它披上组件的皮，这极大地限制了开发的灵活度，比如为保证效率，组件要求走事件循环及NIO，一般情况下不能有阻塞代码，这对应用开发的限制就很大；
  4. 另外还有一些上图没能表述的问题： 日志过于分散，不利于跟踪，一次请求经多个组件，日志被分到不同组件中了； 缺乏I18N支持； 模型设计得过于复杂。

  针对上述问题我目前在重新设计2.0版本，总体思路是分离应用与组件，由之前的类OSGi方式改为当前流行的开放平台(API)方式其架构如下：  

主要的变化在于：

  1. 应用与中间件平台分离了，平台内所有组件只走事件总线；
  2. 应用与平台交互支持HTTP及Socket两种方式通讯，前者对防火墙友好，后者效率高；
  3. 应用的开发技术不再被限定，只要加入Client包就可以与平台交互，对于简单的应用可直接用js版本的client开发无后端的应用；
  4. 透明代理方式，所有请求都交由proxy组件完成；
  5. 认证只在proxy的拦截器中做一次，也就是说一次请求（无论有多少个子请求）只做一次认证；
  6. 统一日志，引追踪日志，把同一请求的日志串在一起；
  7. 加I18N支持；
  8. 提升标准代码（返回码）的支持力度；
  9. 模型简化，内核重构。

  中件间的开发很有意思，对公司而言拥有一个成熟稳定的中件间平台更能极大地减化项目成本、提升项目间的聚合度。

Building Beautiful Life