应用系统架构演变初探

背景

近几年的互联网创业风潮持续在高涨中,所涉及的行业从涵盖了社交、资讯、电商、生活服务等方方面面。其中也涌现不少优秀的APP,而这些产品或平台的特点都包含了"快速",即更新快,迭代快的特性。

然而作为一名软件工程师的角度,按以前软件工程的理论来说,系统在设计初期应考虑更多的复杂度、良好的扩展性,尽可能达到以不变应万变的结果,而这些快速变更的新秀产品,在系统架构上如何做到灵活扩展、快速演进的呢? 这便是以下要开始探讨的内容。

一、初定系统架构

在最开始的时候,产品经理(或项目经理)找到你,在唠唠叨叨叙述完整个系统的功能需求后,要求你一个月内就开发出来。

经理:
    "领导那边催得要命,一个月内必须上线!"
    "这些功能都很常规呢,需要开发这么久吗!"

你:
    ...

当然,以上的场景稍显夸张,但在互联网思维方式的APP开发场景下,这样的节奏其实很常见。

研发经理都是任劳任怨的角儿,于是乎,大脑开始高速运转:

"这么短的的时间" .. "好吧,先不考虑性能问题了!"
"单元测试也可以省了,做好自测就可以,能省下不少时间呢"

经过一轮挣扎和思考,研发经理推断出了产品的第一代系统架构

架构特点

单点,以满足功能为主,简单、轻量级架构。

数据流

来自多种场景的的http请求直接由单个server接入、完成业务逻辑处理、输出计算结果。

组件介绍

1    App Server,应用系统的服务端节点,可以有很多种选择,以Java系列为例:

tomcat

最流行不过的j2ee容器,官网 http://tomcat.apache.org/

jetty

一款更为轻量级的servlet容器,轻量小巧,提供可编程server的实现(容易嵌入),在continuation机制也有比较良好的表现。

详细参见 http://www.eclipse.org/jetty/

playframework

此前最为喜爱的一款非主流应用服务器,应该是首个java版本的"ruby on rails"的实现。其摒弃了j2ee繁重的各种理念枷锁,让编程变得更加简单、可依赖。

playframework框架目前已经主推2.x (同时支持java和scala)版本,然而学习曲线相较1.2.x版本更加陡峭,建议可从1.2.5版本开始入门使用。

值得一提的是该框架内置了netty以支持http请求的接入及处理。

netty是一款基于NIO实现的轻量级http服务器,

关于netty的实现原理可参考: http://stonexmx.blog.163.com/blog/static/122158587201061331614536/

play框架的官网:https://www.playframework.com/

2  mysql,流行的开源数据库,应用基于JPA/JDBC进行访问,以实现数据持久化

3  memcached,高速的内存服务器系统,支持KV数据流的快速读写,用作数据缓存及加速访问

官网地址:http://memcached.org/

二、演变的开始

好的,经过一个月的努力,系统上线了。

运营也开始干活,紧接着是对线上各种问题的紧急修复。

系统渐渐有了一些活跃度,在几个月内,产品经理和研发经理开始听到了一些抱怨:

 "系统怎么老挂啊,动不动就访问不了,这什么破玩意啊"
 "我这都已经换成wifi了,图片怎么还是一直加载不了呢?"
  .....

所谓积少成怨,团队终于顶不住压力,下决心开始优化系统。针对上述的问题,分析如下:

1  可用性;

单点发生崩溃,整个系统直接不可用,所有用户将受到影响;

JVM的内存溢出,系统进程意外终止都可能导致这样的问题。

2  带宽;

应用系统在初期设计时更多的考虑了网络调用、html动态页面的输出,而针对图片的访问并未做过多考虑,因此文件资源访问很快出现了瓶颈。

研发经理决定将架构优化如下

 负载均衡

使用nginx提供应用服务器的负载均衡,提供两个应用服务器节点,保证单点崩溃时而系统仍然可用。

文件访问分离

使用单独的web服务器(nginx)用作文件访问服务器,所有的静态图片地址将指向独立域名。

三、加速进化

继上一次优化之后,用户的抱怨已经明显减少,产品经理和领导都对此次工作表示满意。

研发经理开始感受到了前所未有的成就感。

然而好景不长,在几个月后公司重点引入了营销团队。这是相当给力的团队,在短短的时间内,在各大网络平台布置了多个入口。

各种推广活动、事件营销接踵而来。最可观的如在微信朋友圈的一次事件营销直接引入了好几倍的用户量。

这样的情况在互联网产品的发展轨迹上至少也可以称得上一次小小的爆发式增长了。

当然,领导、产品经理都开心和兴奋起来了。但这次,研发经理内心开始发愁了:

1  访问压力;

一个server的并发处理能力很容易达到上限,一旦超过负载阈值,将直接导致访问时长加大,甚至系统崩溃、无法访问等情形;

2  数据存取;

数据量的扩充,单个数据库表不断增大,查询速度将产生下降;

此外数据库的单点也成为隐患

3  缓存空间;

与数据库同理,为加速更多数据的访问,需要提供更大容量缓存空间;

这次,研发经理将系统架构做了一次较为彻底的改进:

负载均衡

增加负载均衡的服务器节点,提高整体处理能力;

数据库扩展

采取水平切分的方式,实现基于Shard的分布式数据库集群;

memcached集群

开启多个memcached节点,组成高可用的缓存集群,同时可支持更大的缓存空间

其中对于服务端程序改造最大的在于分布式Shard数据的实现,一般可从数据量较大的局部表开始切分,在数据存取上加入水平分库的机制;

当然此时的数据迁移工作也是一个重点。

四、未来的展望

至此,系统优化已经告一段落。当前的后台架构已经处在一个表现稳定,容易扩展的一个状态。

性能指标方面大致已经可以达到百万级用户量,日PV过百万,甚至还可能更好。

然而这还仅仅是一个雏形,应用系统的场景是多种多样的,在未来需要解决的问题往往不仅仅这些,比如:

1  系统存在全文搜索、或是标签式搜索的场景,为了提高搜索性能,你可能会引入sphinx中间件;

sphinx的中文版本为coreseek(可支持中文全文搜索),。

详见官网:http://www.coreseek.cn/

2  为了提高事务处理的效率,你需要队列服务器来解决,这个可以是ttserver + worker的模式;

3  频繁的处理缓存数据的解析在开发上会比较麻烦,你还可以更换redis来直接支持数据结构式的缓存...

redis为一款支持数据结构缓存及数据持久化的优秀的nosql中间件,

官网地址:http://redis.io/

备注

架构设计需秉承的"适用"原则,不同业务场景所采取的架构都会有些差异,此处仅仅讨论最常见的扩展思路,关于读写分离、数据主备等做法在此不做讨论。

本文所提及的故事情节均属杜撰,如有雷同,实属巧合。

原文地址:http://littleatp.cnblogs.com/p/4374679.html

时间: 2024-10-19 09:47:04

应用系统架构演变初探的相关文章

APP系统架构设计初探

一,图片体验的优化. 在手机上显示图片,速度是一个非常重要的体验点,试想,如果您打开一个网站,发现里面的图片一直显示失败或者是x,稍微做得好一点的,可能是一个不消失的loading或者是菊花等等,但不管如何, 没能快速的拉取和展示图片对用户体验是一个极大的挑战.那么,手机上的图片体验如何做呢?这里笔者有些小总结: 1,减少图片的大小.在失真度和图片大小中做好折衷,尽量利用工具减少图片的size,也可以考虑利用不同的图片格式. 2,减少图片的请求数.可以考虑把多个图片利用类似css sprite的

《唯品会峰值系统架构演变 》

唯品会每年最大力度的促销活动在4月19日,就是419(For One Night),意在告诉唯品会用户只有这一晚有这么大的折扣力度(本文中用“大促”就指代419) .唯品会是一个闪购网站,用户来得越早,越能买到又便宜又好的东西,所以在大促的一开始,会涌入大量用户,形成系统流量峰值. 本文总结了唯品会419时日志平台遇到的问题和解决方案,同时根据实践经验,整理了在面对峰值前要做的准备. 唯品会的日志平台,包括消息中间件.计算和数据可视化.前两者和峰值系统相关度更大一些.在2013年419时,我们使

应用系统架构的发展历程

 应用系统架构演变初探 背景 近几年的互联网创业风潮持续在高涨中,所涉及的行业从涵盖了社交.资讯.电商.生活服务等方方面面.其中也涌现不少优秀的APP,而这些产品或平台的特点都包含了"快速",即更新快,迭代快的特性. 然而作为一名软件工程师的角度,按以前软件工程的理论来说,系统在设计初期应考虑更多的复杂度.良好的扩展性,尽可能达到以不变应万变的结果,而这些快速变更的新秀产品,在系统架构上如何做到灵活扩展.快速演进的呢? 这便是以下要开始探讨的内容. 一.初定系统架构 在最开始的时候

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

大型网站系统架构的演化(转)

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

大型网站系统架构的演化

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

微信架构演变

从无到有 2011.1.21 微信正式发布.这一天距离微信项目启动日约为2个月.就在这2个月里,微信从无到有,大家可能会好奇这期间微信后台做的最重要的事情是什么? 我想应该是以下三件事: 1. 确定了微信的消息模型 微信起初定位是一个通讯工具,作为通讯工具最核心的功能是收发消息.微信团队源于广硏团队,消息模型跟邮箱的邮件模型也很有渊源,都是存储转发. 图 1 微信消息模型 图1展示了这一消息模型,消息被发出后,会先在后台临时存储:为使接收者能更快接收到消息,会推送消息通知给接收者:最后客户端主动

大型网站系统架构演化之路

前言 一.最开始的网站架构 二.应用.数据.文件分离 三.利用缓存改善网站性能 四.使用集群改善应用服务器性能 五.数据库读写分离和分库分表 六.使用CDN和反向代理提高网站性能 七.使用分布式文件系统 八.使用NoSql和搜索引擎 九.将应用服务器进行业务拆分 十.搭建分布式服务 小结 前言 一个成熟的大型网站(如淘宝.天猫.腾讯等)的系统架构并不是一开始设计时就具备完整的高性能.高可用.高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计

大道唯简----存储架构演变之剖析

随着云计算和大数据的发展,传统的基于主机的存储架构已逐渐向网络化.虚拟化.海量云存储发展,从分散走向集中,存储的性能.效率和扩展性.灵活性被企业普遍关注.从更高层次看,存储不仅需要提供数据的管理.数据复制.快照.镜像.迁移等例行性事物,更要能处理数据的灾难恢复.数据一致性.虚拟化融合.弹性计算与资源扩展等工作,这些都依赖于良好的存储架构来满足. 结合企业的IT建设,我们可以把存储架构的演变归纳为三个阶段. 第一个阶段是存储基本架构的演进过程. 在企业建立初期,用户的数据规模并不大,存储需求也相对