对 Workflow 架构改进的猜想-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

对 Workflow 架构改进的猜想

简介:

开发 workflow 已经是两年前的事了,那是我第一家公司的第一个有形产品,也是我主导开发的。在这里,真的要感谢以前的主管,使我从一个程序员爬到了技术主导的位置。

workflow 的项目背景是这样的:公司是个集团公司,主产业是制造和电子,开发人员有几百号,我们属于第二个事业部,用这个系统的有管理层,业务层大约上万人,每个月的数据量为 200多万笔,这个产品只是内销。就是在这样的背景下公司组了 20 个人的团队,在两年的时间开发了 workflow 系统, 它的开发语言是 Java, 总体架构是 Struts+Hibernate+Spring, 有 J2EE 的部分,也有 J2SE 的部分,采用的标准是 WMfC.

当时数据库只有一个(Oracle 数据库),在单独的服务器上,配置很高,Web 服务器也是单独的高档机,还有就是客户端的 Application. 典型的三层架构。这样的系统能够有多大的吞吐量呢,性能如何能,可想而知。系统的性能没有禁得住应用的考验,于是我们反思了,从新考虑了系统架构。发现瓶颈在数据库,不过那时我就离职了,在公司整整呆了 2年零6个月。

事隔这么久,只有猜想当时该如何如何。猜想 workflow 已经超负荷工作了,数据库占了大量 CPU 资源, 系统没有扩展性!猜想workflow 以服务的方式加入了互联网,用户超过 1 个亿。

从下面两方面改进系统。

1. 数据库层的架构改进:

第一个观念就是数据的读写分开,比如用完全一样的数据库,一个主数据库用来写,其他从数据库用来完成读操作,隔段时间将写数据库同步更新到从数据库中。

用户表是个大表,超过一个亿的资料,检索更新速度很慢。于是把用户表单独放在一个数据库服务器中,并且按照用户的所在省份水平分割成多个表,每个表就有 300 多万的数据,查询可控制在 1 秒之内。

表单流量很大,每月上千万笔。同样,表单表按照功能分割到多个数据库服务器中,每个数据库中再按照表单类别水平分割。这样在增加表单时,可达到服务器的线性扩展。

Oracle 在分布式方面做得很好,可以充分利用这个优势。

数据库的缓存
2. 应用层的架构改进:

尽量做到动态网页静态化,比如在流程中跑的一个固化的表单不应该动态生成,而应该在提交表单时就做静态化。

使用缓存。有些网页,像首页,可以学习百度首页,缓存24小时。

做镜像服务器

使用负载均衡技术,比如 DNS负载均衡,四层交换机负载技术等等很多现成的方案可遵循。

对系统局部模块优化。不要自己设计模式,现有的模式很多,可以参考。

引入中间件技术,对源有系统 SOA 的观念做集成和整合。比如整合 ERP, EIP,EPP等系统到 workflow中。

本人在系统架构方面经验比较少,在系统分析方面做得工作比较多,请 blog 朋友多多指教

本文转自BlogJava 新浪blog的博客,原文链接:对 Workflow 架构改进的猜想,如需转载请自行联系原博主。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: