归档于 七月, 2010

31
7月

互联网产品服务品质杂思

   前两天接到了蜘蛛网客服的电话,说我年初通过他们网站订阅中国经营报时候,中国经营报赠送 […]

25
7月

复杂事件处理(Complex Event Processing)入门1

    一个新产品需要重点考虑业务风险控制。关于风险控制系统整体的技术方案可以参 […]

18
7月

互联网产品重构

1、为什么要进行产品重构

旧系统人员流失,系统的业务规则、原始需求谁都不清楚,需求文档、使用文档、架构文档极其缺乏,成为一个无底洞,可维护性很差。

旧系统越来越复杂,潜规则太多,原本修改一个小需求,一不小心搞得上线后影响一堆用户

旧系统的业务架构、技术架构无法满足新的业务模式需要

旧系统性能无法满足公司业务高速发展的需要

旧系统的产品生命周期已经到头,需要延长期生命周期

等等

2、产品重构 VS. 重做新产品

对现有产品进行重构还是重新做一套全新的系统并没有标准答案。技术人员们都倾向于重做新系统,并都倾向于高估自身的管理能力、架构设计能力,大家都会承诺完美的架构、完美的产品规划。但如果没解决根本性的管理问题,重构或是重做宿命都是一样的。这些管理问题包括产品规划能力、业务架构能力、项目管理能力、架构管理能力、架构设计能力等等。

在管理能力尚未改善的情况下,怎样保证重做新系统时候不落入旧系统“新做系统,承诺完美架构->管理失衡,系统维护陷入混乱->再重做新系统”同样的命运。好的架构是管理出来的,不是设计出来的。

产品重构第一困难的是反向工程过程阶段,必须搞清楚现有系统的遗产状况。对于一个在线运营的系统,不管是重构还是重做都必须经历此过程

产品重构第二困难的是旧系统迁移到重构系统的过程。怎样做到不影响现有客户使用的情况下完成灰度切换,这是最大的挑战。不管是重构或是重做都必须经历此过程

3、关于产品重构的思考

4、参考资料

The Product Re Architecture

利用 RUP 对遗留系统进行逆向工程

软件架构的艺术

Technorati 标签: Architecture Reconstruction,architecture recovery,产品重构,架构重构,反向工程,正向工程

11
7月

关于团队成员利益选择的思考

    公司组织机构调整,团队职能重新分工,团队核心骨干员工成为各部门竞相游说的 […]

10
7月

交易系统“热点账户”处理

对于在线交易系统,由于存在大量的并发事务需要处理,数据库成为整个系统最大的性能瓶颈。数据库服务器可以通过“垂直扩展”、“读写分离”、“分库、分表(分片,sharding)、分区,读写分离”(参考Data Access Layer(DAL)方案 )等手段来提升系统并发处理的性能,但相对于诸如大量并发事务更新同一账户余额(所谓的“热点账户”)这样的应用,上述手段仍然没有从根本上解决问题,总结一下对于“热点账户”常用的处理手段。

Technorati 标签: 热点账户,交易系统,乐观锁,乐观离线锁,高性能服务器,sharding

    RSS订阅

    近期文章

    近期评论

    文章归档

    分类目录