我们处于恶性循环中，不能自拔

　　我们在努力，一直在努力向前奔跑，但随着日积月累的承载，我们跑不动了，并不是我们偷懒了，而是我们肩负着太多、太多。该停下来，停下来思考了。

　　部门经理来了，怎么回事？为什么系统又奔溃了，你们的年终奖别想要了。该停下来，停下来思考了。

　　客服反应，你们的系统让用户焦虑了，我成了出气筒，我不干了。该停下来，停下来思考了。

　　是啊，以上的种种，时常在我们身边演绎着，作为架构师，作为项目经理，作为研发人员，作为测试人员的你、你还有你，该停下来，停下来好好思考了。。。

一、案发现场，事件回放

我们不是故意的，我们很努力在做

　　上图是我从早期系统中抽出来的三个子系统，却很好的暴露了问题。系统很脆弱，一碰就碎，需求稍微一变动，我们就得抓狂。

　　上图中，我们应变信息孤岛主要采用的技术手段：

　　1、数据库视图

　　2、Web服务（RPC，RESTful）

　　问题来了：

　　1、没有标准，服务满天飞，不好管理，无法重用，而且各种技术交叉使用，混乱；

　　2、系统间耦合度高，一个系统奔溃，另一个系统也罢工了，一个系统对另一个系统依赖性很强。

　　3、系统间业务缺少原子性操作，总是发生莫名其妙的错误，总是多些莫名奇妙的数据，更重要的是，一笔错误的业务数据，给企业带来的灾难，比没有数据更大；

　　4、不稳定、没有容错能力，用户提心吊胆地使用，一错就得重来，没有商量的余地；

　　5、扩展性差，业务需求变动，大改特改，系统遇到性能瓶颈时，无法横向扩展；

　　6、异常很难跟踪，错误发生了，往往需要投入大量的人力、物力，成本直线上升；

　　7、系统间是透明的，团队间协作开发，必须进行大量沟通、会议，才能确保对接接口正常工作；

　　8、我们对研发人员要求过分了，我们的研发人员既要掌握数据库方面的技术，又要去研究Web服务技术。过分，学、学、学吧；

　　好吧，给用户添了这么多堵，我们很抱歉，我们积极改善。

二、转变

　　如果，如果公司业务不再变化，如果用户还是那么具有耐心、好的脾气，那么，那么我们一直这样，也不会出现大的纰漏。好吧，我们就等着失业吧，没有我们，系统也能跑下去。或许，我们应该感谢业务的变动，这样我们才有机会停下来思考，去弥补不足。

　　2012年，企业发生了重大的事件，与同行业另一家公司合并了，现有的系统已经远远不能满足业务变更了。本来还满心欢喜，坐等加薪的心情，一下晴天霹雳了。很明显，内部错综复杂的系统很难去适应如此伤筋动骨的变动了，即使慢慢来，那也是一动百动，牵一发而动全身。怎么办？想办法。

　　其实，我们已经有一个好的转变，早期项目，采用的是数据库视图来解决系统间集成，而后期的项目则采用了Web服务，尽管，只是向前跨了小小一步，没起到多大作用。视图，如果仅仅是用来与第三方系统做数据对接，还能应变自如，但当大量系统间发生业务往来，这时，只能望而生畏，何况还有个不同数据源需求在那窥视着。Web服务在系统集成方面起了很大作用，你只要发布个服务，遵循协议下，则可以很好地做到多个系统交互，处理相关的业务。

三、应对之道

我们已经迷失了方向

　　正如上图所示，我们应用了Web服务，解决了多个系统间的业务集成问题，但随着业务增长，项目成长很快，我们的web服务出现于各个业务系统中，他们不受制约，他们开始横行乡里，从而导致系统结构错综复杂，超出管控。

　　我们该做点什么了，管理好我们的服务，得让他们认识到法律，奉公守法。

什么表情，也阻止不了我们的决心

　　服务处处见，凌乱不堪，如果我们迁移了一台系统服务器，会发生什么？其他系统找不到调用服务了，改下注册服务的配置文件就行，分分钟的事。是这样吗？哪些系统调用了这个服务？这些操作，人为去做，想不出错，很难。

我们一直都在

　　我们需要一种机制，一种能够统一管理服务的机制。我们不用去关心服务最终会部署到哪里，不用关心服务如何被调用，换言之，我们只应向外发布一些的消息，或者订阅我们关心的信息，其他的所有一切，都应该让这个机制帮助我们去处理。终于可以拨开云雾见月明了，上面所描述机制的产物，他有一个名字，叫ESB。

　　ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口（引用自百科）。

　　看完定义，我们知道，ESB应该具备提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能。在此基础上，我们的业务功能能够被发布、封装和提升为服务；服务应该可以被编排，以达到复用的效果。

　　仅仅这些，还不够，我们需要一套管理工具，我们要随时跟踪、查看服务的状态，我们要对服务了如指掌，一出问题，立马解决；对于网络突然中断我们应该提供一个反复尝试功能，而对于断电或一切不可抗力造成的系统中断，我们应该提供一定的容错能力。

　　如果允许，我们还应该拥有一套开发工具，来快速构建模型、开发服务。

我们时刻准备着

　　如上图，我们大概的轮廓已经出来了，我们需要依靠他去把系统构建得更可靠、稳定、健壮，至少要让用户大胆地使用。

四、技术选型

　　我们的项目，大多数是基于微软.Net平台开发的，使用的是C#语言，并且，我们要做的是改造，而不是推倒重来（想都别想）。

　　开发语言确定下来后，我们的工作有以下几种选择：

　　1、自主研发出一套平台

　　2、找开源项目，基于它做二次开发

　　3、购买第三方的平台

　　我们选择的是NServiceBus，虽然是开源的，但开源条款对我们来说并不是免费的。

　　暂到这里吧，不知不觉啰嗦了这么多。

　　未完待续……

 ——Aaron.Pan 2014-08-21:20

关于企业管理系统集成那些事