发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 CQRS

一个常见但不是那么容易的架构问题

                   
kri
2011-11-04 16:41
赞助商链接

很多互联网或者企业系统,都是前面一个线上运营系统,后台一个内部管理系统,共享一部分库表数据,各部分都是运行在各自不同的进程,比如s2sh系的,打开hibernate缓存,那么运行在不同进程内的各运营子系统之间,以及与内部管理系统之间,如何既能利用缓存,也能避免数据脏问题。我们现在是用消息弥合的,但有没有更成熟的方案。各位方家,望赐教

1
2011-11-05 07:57

2011年11月04日 16:41 "@kri"的内容
我们现在是用消息弥合的,但有没有更成熟的方案。各位方家,望赐教 ...


基本是这样,消息+服务,每个系统之间都是和服务(Web服务)接口耦合,服务的调用有通过消息或通过服务发现机制实现同步调用两种方式,基于服务的方式易于发展为平台。

提供一个参考:Steve Yegge对Amazon和Google平台的长篇大论

1) 所有团队的程序模块都要以透过Service Interface 方式将其数据与功能开放出来。(陈皓注:Service Interface也就是Web Service)
2) 团队间的程序模块的信息通信,都要透过这些接口。
3) 除此之外没有其它的通信方式。其他形式一概不允许:不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等,等等,唯一允许的通信方式只能是能过call Service Interface。
4) 任何技术都可以使用。比如:HTTP、Corba、Pubsub、自定义的网络协议、等等,都可以,Bezos不管这些。(陈皓注:Bezos不是微控经理吗?呵呵。)
5) 所有的Service Interface,毫无例外,都必须从骨子里到表面都要设计成能对外界开放的。也就是说,团队必须做好规划与设计,以便把接口开放给全世界的程序员,没有例外。
6) 不这样的做的人会被炒鱿鱼。
7) 谢谢,祝你有个愉快的一天!

[该贴被banq于2011-11-05 07:58修改过]

kri
2011-11-08 13:59

2011年11月05日 07:57 "@banq"的内容
基本是这样,消息+服务,每个系统之间都是和服务(Web服务)接口耦合,服务的调用有通过消息或通过服务发现机制实现同步调用两种方式,基于服务的方式易于发展为平台。
...


对,我们是做了个能力层、服务层、服务管理层、客户端调用层,各层通过web服务或消息进行发现或者调用。但是在服务层内部,2个服务之间,需要继续考虑边界划分,比如发帖和审批分属于前后台服务,可能是由不同小组开发,发帖服务发帖之后,缓存了帖子对象,审批服务审批之后,如何通知发帖服务更新?

我们现在是在前台发帖服务增加了一个通知接口,后台审批通过时,1个后台审批通过服务实例向多个前台发帖服务实例发送异步的已审批通过通知。如果前台服务崩溃,后台审批可以照样进行,当前台服务重启时,会加载已审批的结果。

老彭,还有更优雅的做法吗。

2011-11-08 14:33

2011年11月08日 13:59 "@kri"的内容
老彭,还有更优雅的做法吗 ...


成熟做法基本是这样,如果还有什么问题的话,根据问题有不同方向选择,比如可以向Event Sourcing方向发展,以事件为主要考虑;或者象Amazon那样从SOA发展为云计算平台。



kri
2011-11-08 14:56

2011年11月08日 14:33 "@banq"的内容
根据问题有不同方向选择 ...


嗯!soa->cloud,一个很自然的演化结果。

event sourcing这样的利刃,密切关注!

分布式系统      缓存      多层分层架构      SOA     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com