关于系统集成的一些想法，及再次讨论B/S、C/S

阅读更多

最近在罗马尼亚做需求调研，发现用户在工作中，需要频繁从10个系统查看数据，辅助决策。于是就想是否有可能做一个信息聚合的系统，让用户不需要频繁地“切换”和“根据关键字检索”

今天晚饭时和同事讨论了一下，有一些零碎的想法，在此记录

我认为这里有2个层面的问题，第一个层面是集成，第二个层面是信息搜索。分别对应用户的2个动作：“切换”、“检索”

首先谈集成层面：

问题的本质在于，这个新系统（下文简称A），需要和现有的10个系统集成起来（老系统是处于“被集成”的位置）。归纳起来，我认为一个系统是否容易“被集成”，可以分为3个层次：

1、展现层接口

第一种情况是，系统对外提供的是完整的界面，即“展现层的接口”

比如输入一个www.somesystem.com/sla/aug，某系统返回一个完整的页面。那么如果A要集成这个系统，就直接将这个页面嵌入到自己的界面中；

或者发送一个指令如“kpi=sla/aug”，某系统返回一个完整的flash。那么A也可以直接把这个flash嵌入自己的界面

这种情况在老的B/S架构应用中是比较常见的，比如我要把“博德之门2”的信息集成进来，可以直接在A的界面中嵌入 http://baike.baidu.com/view/6246506.htm?fromId=2761385，集成难度非常低（当然这是盗链，只是打个比方）。另外大部分的企业B/S应用都有鉴权机制，所以也还是需要解决SSO的问题

在C/S架构中这种情况非常少见，因为client层的处理能力很强，不太需要在网络中传输这么大的流量

这次目标的10个系统中，大概有3个是这样的类型

2、业务层接口

第二种情况是，系统对外提供只是数据片段，即“业务层的查询接口”

基本上所有的C/S架构应用都是这样的，比如我在DOTA中潇洒地补刀，补刀了一个投石车，得到了70金币。server传给war3 client的只是类似“hit=yes;gold=+70;unit=destroy”的数据片段，而不是把整个补刀的动画传过来，动画是根据这些数据，在客户端上计算得到的

问题在于，这里的“接口”可以说是一厢情愿的说法，事实上大部分的C/S应用是private的，并没有打算将来给别的应用去集成，所以这个接口虽然存在，但是并不是开放的。也就是说我想要得到上面的“hit=yes;gold=+70;unit=destroy”数据，唯一的办法就是打开客户端，然后认认真真地补中一辆投石车（好吧，这也不是很难），很难通过写代码的方式来模拟这个事情。各种游戏的外挂，实际上干的就是这样的事

老的B/S应用，主要还是第一种情况，很少用第二种。主要是因为浏览器的渲染能力比较弱，计算也比较慢，所以还是把大部分的工作在server端完成，client只原样展示。但是这种情况在最近5，6年有了明显的改变。主要是由于PC的性能越来越强，js、css也赋予了浏览器足够的逻辑运算能力和界面展现能力，AJAX技术在其中也起了至关重要的作用。总的来说，现在的B/S架构应用，也越来越倾向于“薄server，厚client”，甚至很多C/S架构的老系统，也开始推行“WEB化”。这样的例子很多，比如博客园、当当网现在的首页就完全是通过ajax加载的，还有大量的网页游戏等等。其中的驱动力主要是减轻server端的压力，将计算压力分摊到client上；而client的能力和技术进步，使得这个愿望成为可能

我们以前做过的一个系统，就是这种形式，通过http://www.company.com/workorder/username这个链接，返回某用户的工单数据。浏览器拿到数据以后，刷新DOM元素；而android终端拿到数据以后，刷新手机界面。这个接口，就是典型的业务层接口，无分B/S还是C/S。Remedy也是这种做法，AR Server暴露的就是各种业务接口，并提供了SDK让客户自己去定制client；同时官方也配套提供了一个mid tier，包装出了简单的URL，初级用户可以直接用浏览器来访问mid tier

要集成这种类型的系统，就根据协议向server端发起请求，拿到数据后自行组装。然而问题在于，老系统这一层的接口，也不一定是开放的

10个目标系统中，大概有4个是这种类型

3、数据层接口

第三种情况是，系统将数据直接通过接口暴露出来，要什么就自己取。这个比较难举出例子，毕竟很少见。欧洲有些厂商的IT整体架构就是这样，底层是一个数据仓库，然后暴露了一堆查询接口。上层的应用系统是按需定制开发的，可能一个系统取了123数据来展示；另一个系统取了456数据来展示

这里的数据仓库，可以有多种形式，可能就是一个标准的RDBMS，开放了一个SQL接口（危险）；也有可能是加了一层很薄的帽子，看起来类似第二种情况，但是可以更有效地做日志、权限控制、防SQL注入等

集成这种类型的系统，其实意义不大，因为对方的数据也不外乎是从数据仓库取的，既然老系统能取到，那么A当然也能取到。那么去集成老系统反而是多此一举，不如直接也从底层的数据仓库去取，关键还是搞清楚业务规则，别人为什么要这么取

10个目标系统中，最后大概有3个是这种类型

总的来说，我觉得没有明显的优劣之分

第一种方式最为省事，因为封装得最彻底最粗粒度。A要集成这种系统很简单，但是要做定制则非常难。比如对方系统提供了一个页面，如果我们只想直接复用，那就最好。但是如果我们只想要页面里3个字段的2个，那么就需要处理这个页面，从中间剥离出来，难度就很大

第二种方式只提供数据，封装程度比较弱，细粒度，就给A的定制提供了更多的可能。但是相对的，A在界面开发上就需要更多的工作量

第三种方式则更彻底，没有任何封装，相对的就连业务规则也没有了。A想要什么就取什么，相对地工作量也就最大，某种程度上算是新开发一个系统，也谈不上什么集成了

从我来看，第一种方式封装过度，客户端的自由度太小；而第三种方式的粒度又太细，定制工作量太大，也缺乏约束。这两种方式都太极端，所以折中的第二种相对是比较好的，对一个开放系统来说，现在主要也是采取这种方式，比如各种开放平台的SDK，其实就是这种方式

下面谈一下搜索层面：

相对于前面讨论的集成层面来说，搜索层面没有太多可说的，本质上取决于对方系统接口的粒度和开放程度

比如说，假设我现在想做一个书籍信息的垂直聚合应用，那么我当然要去当当、亚马逊、京东、china-pub上拿信息

某网站开放了接口（无论是上述哪一层的接口都无所谓），就比如说是web api吧，有queryByIsbn()、queryByAuthor()、queryByPrice()这3个方法，那么我就可以根据条件，去调用这些接口，来精确搜索到我想要的信息

而另一个网站则非常封闭，就希望读者到我网站来贡献流量，不要第三方应用乱戴帽子，那么就只有一个URL，www.bookshop.com/book?id=123456，那么我要在这个网站上做精确搜索“10块钱的JAVA书”就非常难，只能先向“www.bookshop/book?name=java”发请求，从拿到的结果中再解析（需要用到文本解析、正则表达式、去重等），得到我想要的数据之后，再嵌入我的系统里

从上面的例子可以看到，能不能很容易地得到搜索结果，并不是我一厢情愿的事，跟技术能力关系也不大，最关键的因素是，目标系统是否是开放的，在设计的时候是否把“被集成”纳入考虑。遗憾的是，出于商业角度和历史原因，大部分都没有

再举一个搜索引擎的例子，搜索引擎搜网页，一个重要的依据是网页的和