采用SOA后，各个系统如何实现共用部分组件，如头部、底部

0 0

采用SOA后，各个系统如何实现共用部分组件，如头部、底部5

公司的内部办公系统进行了服务化改造，基于阿里的dubbo，最终整套系统运行时包含好多子系统，tomcat之间实现了session共享，通过nginx实现反向代理，使用户看起来还是一个系统。

现在有几个问题一直困惑我：

1、多个子系统中其实有部分内容是相同的

1.1 典型的就是头部和底部，现在是通过ajax请求来实现，但是这样的用户体验非常不好。

1.2 原先在一个系统中可以通过include等方式实现页面的复用，很容易实现如所有页面都要包含一段html的需求。

2、现在按照一个个业务模块进行的划分，包括基础服务，业务服务，项目非常多，服务关系的管理及部署维护的问题也出来了。个人觉得作为一个公司内部的办公系统，其实只要把诸如邮件，消息，文件，索引，权限等进行服务化，为更高层的业务服务即可，还没到需要把所有的进行拆分。

3、公司现在有多个子公司，都需要部署OA，所以又要进行改造，以支持多企业，按照目前的情况来说，如果不解决以上问题，继续进行下去失败的风险很高。

注：开发人员不多就6个。

对于以上问题，希望各位给点意见建议，谢谢！

问题补充：to 鳄鱼旭:
我画了一个简单的图:
https://docs.google.com/drawings/d/1HP1VS5XPj8ecjJO85TKIBXR4wD6Y730o72TeJh0iZhs/edit?usp=sharing
请问为什么引用Frame.jar就可以实现头部、左侧菜单的共用，一般jar包里面都是java代码吧？可以有JSP？这样A、B、C能够成功引入么？还是你用了自定义标签？

我可能忽略的某一点，导致现在有点想不通，可不可以给个简单的流程图或者时序图？谢谢！

SOA

2014年3月04日 23:16

zzzz3621
3
0 0 7

1个答案按时间排序按投票排序

0 0

采纳的答案

SOA并不是意味着要把所有的内容作服务化，需要根据实际的情况（访问量、发布的频繁程度、系统的复杂程度、开发人员的数量、可靠性的需求约束等）决定如何进行拆分：

对于问题1：之前采用过一个做法就是将页面的框架部分单独做成一个Jar包，其他War包引入进来，框架部分做成可以配置的（比如头部和尾部风格变更了，直接修改数据库就可以搞定），不是非常理想，但是解决一般性的不是很复杂的问题足够了；

对于问题2：采用远程访问（dubbo）的方式还是本地API（依赖的内容做成一个Jar包引用起来）各有优缺点：
    。远程：服务之间发布独立、降低Jar包冲突的可能性、管理起来相对复杂；
    。本地API：部署简单、管理容易、Jar包冲突可能性较高、服务之间独立性稍差；

   一般来说是二者结合的：比如Util之类的包一般是API方式的，而底层系统以独立部署的居多

最后：按照6个开发人员的规模，以及应用的场景，建议独立部署的服务控制在12个以内。

2014年3月05日 16:17

鳄鱼旭
248
0 0 17