小规模低性能低流量网站架构设计

很多Web架构的文章都在谈大规模,高流量,高性能之类的网站架构设计,这类文章一是满足人们好奇心,但看过之后也就看过了,实际收益可能并不大;另外一个副作用是容易让人心潮澎湃,没学走先学跑,在很多条件仍不具备的情况下,过度设计、过度扩展(高德纳也说过,”过早优化是万恶之源”),所以,这里反弹琵琶,讨论一下小规模、低性能、低流量的网站该如何架构。
如果站点起步阶段可能就是一台机器(或是一台虚拟机),这个时候,去关注什么数据拆分啊,负载均衡啊,都是没影子的事情。很多大站点的经验绝不能照搬,辩证的参考才是硬道理。
拥抱熟知的技术
动手构建站点的时候,不要到处去问别人该用什么,什么熟悉用什么,如果用自己不擅长的技术手段来写网站,等你写完,黄花菜可能都凉了。所以,有现成的软件组件可用,就不要自己重新发明轮子。人家说 Python 牛,但自己只懂 PHP ,那就 PHP 好了,如果熟悉 .NET?,那也不错。用烂技术不是丢人的事情,把好技术用烂才丢人。
架构层次清晰化
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起,业务一旦扩增开来,如果原有的一堆东西拆不开就是非常痛苦的事情。
Web Server <–> (AppServer)<–>Cache(eg. Memcached)<–>DB层次清晰化的一个体现是(以 LAMP 架构为例):即使只有一台机器,也应该起个 Memcached 的实例,效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上,DB 一旦 I/O 压力走到磁盘上,问题要暴露出来是很快的。没错,DB 本身也会利用自己的 Cache,但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。
数据冗余? 有必要
很多人并不是数据库设计专家,如果应用要自己设计表结构什么的,基本都是临时抱佛脚,但三个范式很多人倒是记得牢,这是大多数小型 Web 站点遇到的一个头疼事儿,一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住,尽可能的冗余数据,你在数据层陷入的时间越多,你在产品上投入的就会越少。用户更关心的是产品的设计。
前端优化很重要
因为流量低,访客可能也不多,这时候值得注意的是页面不要太大,多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人),用户看个页面半分钟都打不开,你说咋发展? 先把基本的条件满足,再去研究前端优化。
功能增加要谨慎
不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销,反而收效甚微。记住,小站点,最有价值的是业务模式,而不是你的技术有多牛。技术是为业务服务的,不要炫技。
有些网站不停的添加功能,恰恰是把这些新功能变成了压死自己的稻草。
从开始考虑性能
这一点是可选的,但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展,很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是,对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。
好架构不是设计出来的
这是最后要补充的一点。好的架构和最初的设计有关系,但最重要的是发展中的演化:
发展–>发现问题–>反馈–>解决问题(执行力)–> 改进->进化到下一阶段–新问题出现(循环)有些站点到了某个阶段停足不前,可能卡在执行力这个地方,来自用户的反馈意见上来了之后,没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词,试想如果不改进业务都没了,那业务还允许么? 其实就是一层心理障碍。

我的IP应用管理

服务器通常不会设置成自动获取ip地址,如果你手下有管理多个服务器,你会发现每次分配新的ip地址都会成为问题,既有很多在用的ip,也有很多保留的ip(通常是为了做NAT)。这个应用程序就是为了管理IP地址儿产生的。

以下是程序的几个截图

 

 

 

先放出链接和用户名,以后再放出源码

http://php-yhjhoo.rhcloud.com:28080/home.php

 

用户名:admin

密码: admin

Scrum的故事

2001年2月,17位敏捷先驱齐聚犹他雪鸟度假村,起草《敏捷宣言》的时候,Scrum只是众多方法中不太起眼的一个。十年之后,Scrum却成为最流行的敏捷方法,几乎成为敏捷的代名词。

本文来介绍下Scrum的两位创始人——Jeff Sutherland与Ken Schwaber。

大家可能不会想到,Jeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务。服役后期,他到斯坦福大学拿下统计学硕士学位,并在美国空军学院教授数学统计学和概率学。11年军旅生涯结束后,他成为了科罗拉多医学院的教师并获得了博士学位。在诺贝尔化学奖得主莱纳斯·鲍林的赞助下,他以放射学、生物学及预防医学助理教授的身份参与了维生素与癌症研究中心的创立,担任八年国家癌症中心的主要研究员,负责科罗拉多地区所有癌症患者的数据统计和IT方案与研究,整合了国家注册、临床试验、流行病学研究和癌变的超级计算机数学模型。1983年,他进入了一家遍及北美、经营着150家银行的公司,职务为先进系统副总裁及ATM业务部总经理。此后,Sutherland先后担任了11家软件公司的CEO、CTO或者工程副总裁,积累了丰富的软件开发经验。

Scrum的另一位主角Ken Schwaber最初的职业也很特别——商船经理。在随后40多年开发生涯的前10年中,他曾经编写过操作系统,搞过嵌入式,为IBM大型机开发系统软件;先后在芝加哥大学、伊利诺伊理工学院、王安公司实验室工作,并逐渐展现出在软件开发方法上的天赋。在CASE工具和结构化方法热门的时候,他自己创办了ADM公司,从事软件开发方法培训服务。期间,公司开发了软件方法自动化工具MATE,用来生成各种软件流程所需的模板、计划等,生意很好。

Sutherland和Schwaber相识于1980年代早期。1987年,两人开始合作。一天,Sutherland问Schwaber:“你们开发MATE工具都用了现在流行的哪一种方法?”“当然什么都没用,”Schwaber回答,“要不然公司早就完蛋了。”他们意识到问题的严重性,开始与开发者交谈,研究新方法。

1993年,Sutherland读到了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现的新的产品开发方法Rugby(橄榄球)的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发,结合自己多年的经验,与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法,取名为Scrum(来源于橄榄球术语,不是缩写)。

而Schwaber则从杜邦公司一位化工过程控制专家那里取经,意识到项目分为两种:确定性项目,一切都已经确定,可以自动化生产流程;实验性项目,充满不确定性,哪怕一点微小的变化也会牵一发而动全身,因此只能用各种仪表不断监控,随时做出调整——这就是每日站会的由来。

两人在一个IBM项目合作,并做了更详尽的研究,Scrum诞生了。1995年OOPSLA大会上他们第一次向世人介绍了Scrum。可当时,两个人的公司都还在做千年虫和各种重型开发方法咨询方面的业务呢。

进入新世纪,互联网带来的巨变使敏捷方法受到了更多开发团队的青睐,而其中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等因素,逐渐成为最受欢迎的敏捷流派。而推出CSM等系列认证,虽然争议颇大,但客观上对Scrum扩大影响力起到了重要作用。

今天,Scrum的影响已经远远超出软件开发,成为零售、军事、风险投资甚至学校里完成各种任务的创新方法,正在改变着世界。著名思想家Steve Denning曾表示,如果有诺贝尔管理学奖的话,应该授予Scrum的创始人。

 

转载:http://www.programmer.com.cn/8231/

 

银行业务调度系统的实现

银行业务调度系统的实现

这个例子是在去年在CSDN上看到了,一直忙就忘记了,今天突然看到就小小研究了一个,不是很难! 但是好久没做这方面的开发,生疏不少,花了我4个小时才整出来!

系统要求在附件上中的银行调度.docx.pdf中,请自行下载!

系统运行结果如图所示:

 

 

所用软件,jdk1.6.X, eclipse JAEE for web developer.

参考文档

http://download.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html

源码也在附件,读者可以自行导入到eclipse中。 执行com.ocbc.view.Operator类即可看到程序运行结果。

 

你可以再这里下载用户需求  银行调度.docx

程序源码:Bank_Simulate