自研ESB需求分析01(7.6)

近期，我们自研ESB的设计器部分功能基本已经完成，因此先分析下还存在的一些功能需求和管控需求。

对于协议转换部分 ，当前已经支持http，soap，jms，ftp和db，在现在的基础上最重要的就是需要再增加对tcp协议的支持。对于tcp协议，当前在金融行业的一些集成中还有使用，比如使用Netty进行的消息集成。

消息内容的转换 ，如果仅仅采用的是http rest和soap的话，最常见的就是xml和json，除了这两种外还有的就是存文本文件。这个在我们采集本地文件消息进行集成中经常用到。因此需要对文本文件的支持，是实际的数据映射，当前主流的方法仍然是采用Xquery或Xlst模板来做。对于Xlst模板映射，虽然会牺牲点性能，但是实现上更加灵活。在设计器中我们也可以考虑增加专门的xlst模板映射组件来完成映射工作。

对于消息发布订阅 ，我始终还是想实现一个能力，即将消息中间件能力封装在ESB总线内部，对于接收消息采用WS服务，同时对于分发消息也采用WS服务。对于消息的订阅信息维护在ESB平台中，因此更加容易来实现服务，消息访问订阅授权。但这种方式缺点就是对于JMS已有的消息持久化，重试机制部分需要重写。

服务访问安全部分 ，涉及到基于IP地址访问授权，涉及到用户名和密码的安全验证，同时基于当前主流的API接口安全机制，实现了动态的Token令牌安全控制。这些基本能够满足服务访问安全的要求。

对于服务访问消息内容项数据安全 ，客户往往有这么一种需求，即对于一个WS服务接口，如果A系统调用不能访问price字段，这就涉及到根据不同的消费方来设置字段级的安全控制。而这个需求当前我们也已经实现，直接在服务访问请求进入到ESB总线后进行拦截，在拦截组件中来实现这种个性化处理。

对于 数据加密 ，实际上在服务集成中很少由ESB总线来完成，因为即使ESB有这个能力，消费方发起请求到ESB这段网络路径仍然无法加密，其次ESB加密完数据送到目标端的时候，ESB在目标端无法发起解密，还需要目标端进行处理。

如果确实需要ESB来提供这种能力，实际上最好的做法是服务消费方调用ESB服务获取到加密算法和逻辑，在消费端本地完成数据加密处理，然后服务提供端根据相应的加密算法和逻辑在接收到数据后进行解密。不然仅仅在ESB处进行数据加解密没有任何意义。

对于封装完成服务的环境迁移能力 ，这个是基本的一个能力，即能够将部署在SIT或UAT环境的服务，自动化的迁移和发布到生产环境去，在整个过程中不再需要重新进行服务封装和部署。即服务部署功能可以拆分为两个功能，一个是服务部署，一个是服务发布，服务发布则是包括环境迁移能力，类似实现基本的DevOps能力。

自服务流程，核心是两个，一个是服务接入，一个是服务订购：

1. 服务接入： 提交接入申请-》审核-》封装部署-》联通性测试-》发布

2. 服务订购： 订购申请并选择服务-》审核-》服务授权开通-》返回订购地址和使用说明

SLA服务等级水平 ，实际上涉及到SLA方面的内容，当前自研ESB上实现的能力还不是很多。这里面有两个问题，第1就是SLA等级如何确定，里面包括了业务重要性和影响，性能性能多方面的内容。在确定了SLA等级后，接着就是SLA等级如何和流控结合起来。

1. 当整个ESB平台资源和性能出现瓶颈的时候，首先要做的是对低SLA服务限流。

2. 当进行了限流性能仍然有问题的时候，则对低SLA服务进行熔断。

权限功能扩展： 对于权限，在前面已经讲了可以根据系统对服务进行授权，只有授权了的服务该系统才能够访问和调用。而这里需要做的扩展就是白名单和黑名单的能力，同时黑白名单应该是消费方系统-》提供方系统的对应关系的粒度。也可以是全局黑白名单。对应白名单就是不论服务是否启用授权，所有服务都能够消费，而对于黑名单则相反，所有服务都不能进行访问。

对于资源监控 ，ESB平台可以集成开源的监控软件来实现CPU，内存，中间件线程，数据库，JVM的监控能力，比如对开源的Zabbix进行集成即可实现。而对于服务本身的运行次数，时间，异常，告警等的监控，包括的统计分析报表，其本身就是ESB服务总线的能力。即能够在ESB一个平台来实现从资源到数据库应用中间件再到服务的全程监控当然是最好的模式。