一个资深程序员看12306

http://blog.csdn.net/nostopstep/article/details/18222629

12306铁路售票系统，这是近两年来难以绕开得话题。在2012年的时候，刚看到谩骂调侃12306售票系统的各种文章的时候，我是其中的一个，鄙视那么大一笔钱，做出来的是啥玩意儿，并没有细想过什么。后来，当我试着从技术角度来分析12306的时候，却是一身冷汗，感慨于谁没脑子，竟然敢接手这样的一个系统，以至于也有忍不住想为其呐喊鸣冤的冲动，但基于多种原因，最后没有写。时值今年，又到了买票的高峰期，当12306再次成为人们关注的焦点的时候，我又重新从技术角度评估了以下这个网站，想通过我这个群体，以一个资深程序员的角度来说一下我对12306这个网站的看法。

一、它具有重要的历史意义。

先不从技术角度出发，仅从该网站的产生和使用角度来说，这具有划时代的意义。首先，他改变了一个习惯，一个多年来大家排队买票的习惯，跟上了科技发展趋势。当手机、互联网等设备成为大多数人的生活必的时候，该网站也随之诞生了，从这个角度讲，它适应了科技的发展，是一个具有里程碑意义的工程，他必然也会成为中国铁路史上重要的一笔。

二、它的诞生周期太短，上线过于仓促。

这个话题，得从访问量来分析。作为一个系统来说，中国的铁路售票系统，但就因为“中国”二字，那么他的庞大和复杂性就是世界唯一的，可以载入吉尼斯世界纪录的。原因就在于人口多，多到什么程度呢？可以这么说，目前还没有一款软件敢说在瞬时访问爆发量上敢于和该系统比肩，即便是腾迅、百度、支付宝等这些知名软件，号称以用户量大而著称的他们，最高峰期的并发访问量，估计连这个系统的三分之一都没有，更不用说用户的每个交易都要和钱相关了，一旦涉及到钱的问题，就需要相当高的安全性，这要求每个用户交易细节都要有很严格的处理日志可以查看，更需要将用户购票信息记录入库。那这就会存在一个瓶颈，一个无法逾越的瓶颈问题，当然，怎么解决瓶颈，怎么更好的避免瓶颈，那架构必须要考虑的问题。

记得当汶川地震的时候，无论是联通、移动、电信等的电话，都出现了十几分钟甚至更长时间陷入瘫痪情况。那时候的电话瞬间访问量，有可能能和这个系统来比肩一次吧。从开发周期来讲，用过并知道问腾迅、百度、支付宝发展历史的人，都想一下他们那个是一年就发展好，推出就有这么大访问量的？即便这么多年了，他们谁敢说能抗得住瞬间如此之大的用户访问量？（注意，我说的是并发访问，不是同时在线，支付宝在双11的时候，不是也瘫痪了一段时间么？对于这样的一个系统，从开始研发到上线，竟然才1年的时间，不得不说，这个推出过于急促，诞生周期短的可怕。

三、他的一些缺陷无法避免，一些则不能说为缺陷

很多人说，12306存在大的漏洞，比如说，身份证可以造假，界面不美观，用户体验不好等，对于这些，那是认知的误区。

首先：身份认证不可能不存问题，任何一个国家，都存在有政府专有网和民众网，比如说部队有部队的专网，公安有公安的专网，普通大众使用的是互联网则是通用的，不能把这些融合到一起，试想一下：如果这些都融合在一起了，那这个国家还有那一部分不容易被攻击呢？特别是对于中国这样的大国来说，不可能把公安网络系统、部队网络系统和普通用户网络系统连接到一起。既然不能连接在一起，那身份证认证当然会存在问题了，那他就只能根据一些基本规则来识别身份证是否合法了，因此，这个漏洞无法避免。或者说还不到解决时机。因此，黄牛党抓这个漏洞，从技术上来说，那是不可避免的。

其次：界面不美观那很正常，这个网站，本就应该是以访问量和实用为主，而不是为了人们在这上面赏心悦目的欣赏，更何况，美化的界面，那是和流量有直接关系的。对于用户来说，你获取到信息的流量可能只是几兆的流量而已，不知道有没有人这么算过：普通家庭，拉上一个带宽，大概是8M流量，一年大概一千左右，如果同时又1000个用户访问一个系统，这个系统如果并发输送给每个用户的流量在2M（256KB*1024 *8，流量是以bit来计算的，1M 一般为128KB每秒，即128 * 1024 * 8b），那么1000个用户就是2G的流量。而一个普通网吧的流量也就是千兆。上了G的流量价格就不一样，那10万用户，20万用户，1000万用户呢？这个总入口的多大的流量？这个耗子会对大？因此，从这个角度来讲，界面够用就行，尽可能的在满足用户使用的情况下减小流量，那么，目前的12306界面，可以说这个水平已经算是不错了。

四：这个项目的投资相对是比较低

很多人鄙视这个系统这么多问题，但起初投入竟然达到千万级别，后续更是过亿或者过了几亿。感觉一定很多人在这里面黑了不少钱，贪污了。

是不是有贪污我不清楚，也不敢肯定的说就没有，但基于我做项目的经历来说，一个这样的项目，投入低于2个亿，假如是我，我是不会接的，说这可能被笑话。不过我又这样一个经历：一个项目，历时3年，前后投入人力500人，投入超过2个亿，最后能同时并发容纳不到50万用户同时工作，但年收益却能达到将近1个亿。那作为一个这么大的项目，又该是多少呢？要知道，一个项目的产出，不仅仅是研发成本，还要附带有软件、硬件、设计、策划、管理等各种成本，研发成本在里面占用的最多也就三分之一。那么投入2个亿做一个铁路售票系统，又不让人批评，同时不能陷入瘫痪。我想这个要求如果真提出来，估计没几个公司敢接，即便真有能力接，相信这些公司也看不起这2亿了。谁愿意为2亿而背负这么大的风险呢？这样算来，这个项目的投资不高，可以说是相对比较低。这应该也是为什么不是一个大公司开发出来的原因吧。

五：这个项目整体架构存在缺陷，考虑不足

不过，这个项目既然作为一个大项目，是为了为整个中国人民提供方便快捷的服务的话，就要站的高度高一些。审视这个项目，作为一个程序员说，我们应该同情他，但作为一个资深程序员来说，我认为，这个项目的设计架构存在一定的问题，风险预估也明显不足。比如说，网站的架构，就不应该仅仅是12306一个域名，而应该分区域架设多个域名，每个域名连接不同的平台，也即把原本是一套的平台，拆分成多套来部署，并设计每套之间的联系。这样，就不至于所有人登录同一个网站了，也就分散了访问量了，比如，我们有叫12305.西安的，有叫12306.广州1；12306.广州2；12306.北京1；12306.北京2；12306.上海1；12306.上海2；等等的。当然，因为我并不了解整个铁路售票系统，具体里面的业务复杂度也难以想到很多，因此，这只是一家之言罢了。

至于其他不可解决的缺陷,也是有的,比如票和人供不应求的局面，那必须得靠运输能力本身才能解决。

上一篇，我是从感官和直觉上进行的分析，可以说几乎没有涉及到技术层面。

但作为一个程序员，仅从感官和直觉上分析，那就不叫程序员了，更何况，我还自诩为资深程序员呢？尽管我一再软件行业跌打了近十年，但资深也不是仅仅靠时间就能说明一切的。因此，我一定不能跑了题，本篇将从技术层面进行简单分析。

一：从平台架构来分析

一个好的系统，必须有好的平台架构，那么什么样的平台架构是好的呢？评价一个平台架构的好坏，我认为主要从五个方面来评判：

高稳定性：系统级平台，稳定压倒一切，没有稳定的平台一切都是浮云。

那么如何使一个平台具有高稳定性能？要想使一个平台具备很高的稳定性，那除了平台服务器程序本身稳定可靠，经得住考验外，还要有冗余备份，即备份得时刻准备着。举个形象的例子，一个富翁，出入都会带上几个保镖，那么如果不发生任何事情，这些保镖的作用就看不出来，就会显的多余，但一旦出了事情，他们的重要性就显现出来了，必须在关键的时候能够顶上去。那这么多的冗余备份，都是要靠钱砸出来的；再换个比喻，一个国家和平时期，看不出部队的重要性，但你敢不要部队么？部队是保护和平稳定的核心内容。所以只是高稳定三个字，那背后付出的代价多大有多少人知道？一个平台，大多数时候冗余备份是多余的，作为公司来说，不可能让其闲着啥都不干。就像保镖一样，闲的时候，你可以帮着开车，甚至送老板娃上学。部队平时搞个演戏，或者抗个洪救个灾什么的，甚至参与到治安维护上，这样就能很大程度的发挥了冗余部分的作用。这也是为啥华为、百度、360、腾讯等很多大的公司，借助自己的优秀平台，来大力发展云盘，云存储的原因，因为他们的冗余备份足够，又不能浪费。

12306作为一个在几天内，访问人数超过全国人口总量的几倍的系统，不可能不去考虑稳定性。

高安全性：平台必须有很强的安全性，能够抗击或者分散大量的攻击；

说完了稳定性，就要说安全性了，安全的重要指标就是用户信息不被盗，平台不被黑掉，大量的攻击不能打瘫痪平台。换句话说，客户端或者Web端你可以瘫痪数次，整个后端支持平台一次都不能挂掉。那么如何架设一个高安全性的平台呢？

首先就要解决的是，用户信息不能暴露在最上层，换句话说，就是用户数据信息尽可能的往更底层去存放。说的更通俗一点，就是用户登录的数据，不能直接放在第一层服务器上。搞技术的，特别是做网站的，都知道，IE通过WebService获取数据，而WebService直接连接数据库。这就是最基础的。这样的网站也是最容易被攻击的，我们应该把数据库向下再隐藏数层级。

其次，就是分散攻击力度。什么意思呢？就是不能让攻击包始终朝着一个方向打，要知道，水滴还能石穿呢？让攻击始终朝着一个点，那攻破是迟早的事。如果让他们的打击从一个点扩散到一个面，每个面都打的不疼不痒的，就解决了问题了。

再次，就是数据传输的安全性，不怕一万，就怕万一，因此所有的涉及到用户安全信息的内容，都得尽可能的加密传输，加密转运。其它还有数据库的访问不要通过传输SQL语句而是改为存储过程访问等。

然而，目前大多数中小公司，数据库的位置都很靠前，甚至一些大公司都有这样做的。分散打击点，是很多公司不会过多考虑的，因为对公司来说，没必要好那么大的资金去整这些，况且，他们的访问量也不大。官网访问的后端WebService，那最多就是设计成集群模式。前端架上个Ngx也就足够了，有多少个公司的官网访问量能每秒达到60万人次呢？有的公司很大，但官网并发访问量每秒不到几万，这样的官网，甚至连集群都不用考虑，只需要一主一备，甚至瘫痪后重启就行了。

但12306不同，因为好汉架不住人多，如果有人存心想对某些官网网站进行攻击，用数十个服务器不停地给你的WebService发无用包。不为其他，只为让你的网站瘫痪，有几个能架的住的？而不幸的是，这样的人还挺多，并且大多数是竞争公司的公司行为。

那再回到12306，每个抢票软件的每条消息都相当于一个攻击包，并且这些攻击包还是合法有效的包，平台不能直接丢掉，必须处理的包，更何况还有通过正常途径买票，不停地刷官网网站的呢？

要想真正解决这个问题，只能是将WebService尽可能的分布式。可以这么理解，一个公司的官网可以同时并发的人数假如说是30万，那100个公司的官网，把他们的并发数算在一起，那不就是3000万了么？所以，12306要想解决并发访问官网，就需要部署100个甚至更多的12306的WebService，那就要申请更多的域名。只有这样，才能保证不被同时瘫痪。但这的需要多大的储备资金？更何况，仅仅这样还不够，还要解决更底层的数据同步问题。毕竟几百个公司有几百个数据库，他们之间不需要考虑数据同步和一致性，但一个公司的话，必须考虑。

高扩展性：好的平台，必须是能够动态扩展几乎任何一部分，并且是热扩展性。

这个很好理解，就是说，当你的平台资源不够用的时候，只需要再配置一台或几台服务，直接插上电，通上网，这些服务器就会自动融入到系统平台中，开始工作并提供服务了。同样，一个服务器如果坏掉了，直接拔掉拿走就行了，而不会影响正在工作的其它系统，也就是说，用户感受不到任何异常。

高并发性：好的平台，必须能够支持高并发。

这个也很高理解，就是访问量的问题，这里说的访问量，是合法数据包的访问量，整个平台，在同一时期，能够同时处理的有效数据。

海量存储：好的平台，必须有海量的存储信息。

支撑高并发的，必定是优秀的存储平台，这个平台，能够适应海量数据的快速存储和访问，这就不能只是数据库了，还要考虑内存存储。因为数据库的存储毕竟是要做I/O操作的，I/O操作必然定会耗时。目前知名的数据库，我比较熟知的有SQL SerVer、Oracle、SyBase、Gbase和MySql，而我这几个数据库中，Gbases是树形数据库，非关系型数据库，是专门针对海量数据使用的，也就是说，海量数据的存储查询，他非常快，什么是海量数据呢？即存储记录以T的倍数来计算的。10T，100T的，他的存储速录快到让人咋舌，每秒钟最高能达到百万条数据。但他也有弊端，对于关系型信息的查找，就很慢了，因此它只能在特定领域使用。而SqlServer的话，如果是12306，不应该选择他，或者说选择他会被鄙视。因为他连基本的跨平台都不能，一般来说服务平台，都在Linux下，可他是微软的，不支持Linux。SyBase则是有点过时的数据库。Mysql做大存储量才5000万条。所以，选来选取，只能是Oracle。他的吞吐速率不高，单纯的查询和插入，他每秒的条数我测试过的最高不足2万条。还没有进行关联操作测试。所以，海量存储仅仅靠数据库是不行得，常用东西还需要放置在内存缓存中，类似Memcache这样的东西，让其和数据库配合使用，才是最优秀的。但，12306的数据，很大情况下，不能这么使用。

另外，一个优秀的平台，还必须是高融合性，即能够供外界快速接入。因此，粗略来说，基于分布式的优秀平台，至少要有如下几个部分构成。

1、用户认证服务器。

2、日志服务器；

3、业务处理服务器。

4、数据管理服务器

5、数据库服务器

6、调度服务器。

7、操作维护服务器

二：从业务分析

综上，一个优秀的平台，诞生时间肯定不会端，投入至少也是千万级别的。而上面这些，对于12306来说，都过于简单。只需要简单想一下，你就知道。12306的平台系统不可能是一个，他是多个平台系统的组合。

1、订票系统：负责票务的查询、预定、票仓管理、用户认证和登陆。

2、支付系统：用来进行购票的支付，锁定票据。

3、信息通知系统：用来进行订票后的通知。

这三大系统的融合，必然不是特别顺畅，他需要银行银监会的协助，联通电信移动运营商的协助。铁路系统的协助。等等，你想到的和你想不到的。这么想来，12306可以称为有史以来，最为复杂的系统了。这么想来，一些什么IT人士不堪忍受而自组团队来开发售票系统，简直是一个笑话。

因此，我们应该用正确的眼光看来看12306，不能仅仅是批判。要理性对待。莫说投入一两个亿，这个系统，投入100亿去做，都不为过，如果这个系统真做好了，那具有划时代的意义，他能做到像颠覆那个通讯公司就颠覆那个，设想一下，如果他又个类似QQ的东西，一下子就聚集了上亿人的账号信息。这是腾讯10年的成果。他只需不到一年就能达到。那他想做其他的，还难么？这么想的话，给他投个100亿，政府可以通过它掌控整个民生民意和经济了。

首先声明，本篇文章内容将和12306没有半毛钱关系，只是对（一）和（二）的延续。

实话说，原本是没有打算写三的，其实最初只打算写个一，因此，当时博客文章命名为《资深程序员看12306铁路售票系统》，初衷也只是想站在一个多年程序员的角度，以多年的开发经验，概要的评价一下这个系统的价值和失误之处，不加褒贬的评价一下这个系统。可没想到事与愿违，引来了一些争论，于是就又有了第二篇，想概要的说明一下平台技术，从平台的角度来概要分析说明一下一个平台的不容易，无非还是想让大家正确看待一个系统，依旧想让大家从技术的角度来看问题，因为只是想概要说明一下。所以，只是沿用了标题，但内容基本与12306没有太多关系了，这也正是留言中很多人说与12306没有太大关系的原因。但不曾想引起了更多的争论，甚至被认为是5毛党，无奈之余，仔细分析留言，发现问题主要集中在三个方面。

1、我真的是资深程序员么？

2、平台架构就那么牛么。

3、12306真的那么复杂么？

围绕这三个问题，谩骂者有之，支持者有之，鄙视者有之，拍手叫好者也有之。以至于把楼层都垒到了80层有余，足见大家是仁者见仁，智者见智，其实第三个问题应该说是平台间融合的复杂度。既然这样，那干脆，我就继续拿标题引用，针对三种言论，尽量从各个角度，来一一阐述一下我的个人见解吧，这一篇，我就先说最简单的东西，就说我对资深程序员的定位和定义吧，后续有时间和精力了，再通过平台的一两个技术点和融合平台的复杂度来写一些东西，要知道，工作得放在第一位，何况我的工作压力相当大呢，因此，即便久等了，也请大家见谅吧。

资深程序员

怎样才算资深程序员呢？我对资深程序员的定位标准如下：

在某个领域有一定的经验，有自己的知识沉淀和积累

我的一个朋友，在音视频这一领域干了十几年，他对音频视频内容的提取，音质和视频质量的处理，音频视频的压缩和解压缩，有了相当的造诣，以至于公司的所有音视频研究，新的算法等，都有他带队去做，而为了更好的提高音视频质量，他经常和中科院、清华、北大等专门搞音视频领域理论研究的博士们来探讨这些算法，以期达到他想要的效果，那么这就是资深。但可能很多人甚至在这一领域干过一些年的人会认为：这有啥？音频视频无非就是压缩解压缩罢了，现在很多资源可以用，一样达到很好的效果，还需要找什么中科院、清华、北大的音视频理论研究领域的人，现在的专家是一文不值，只会骗钱等等的话。那我只能说这些人说话很外行，或者远没有在这方面达到一定的积累，那我就没必要和这些人计较，甚至连辩论的话都不想多说一句。

换个例子说，我有一个搞数据库的朋友，在该领域扎根了将近20年了，他平时很少说话，但只要一说到数据库，他就侃侃而谈，他的一些术语说法，别说我听不懂，甚至一些搞了七八年数据库的人都听不懂，在这些人的眼里，一个看似简单的增删改查，就能给你说上几天，这更是资深，以至于大家碰到他，尽量的不去和他谈数据库方面的东西，那他也就没话可说了，当然，和他打交道，为了避免他成为局外人，我们会说一些老歌曲，这也是他的兴趣。

再举个例子，还是我一个朋友，在用C++做界面方面，已有七年的积累，我认为很难的界面问题，在他那里就是喝凉水，在我想做任何界面相关的东西或者谈论界面的时候，我都首先会找他讨论，他关于界面的简介，我甚至会一字不漏的要求贯彻执行。在我看来，他也已经达到了资深。

而如上三个人，对网络通讯和传输，以及后台稳定和安全方面，并不了解很深，甚至可以说，他们的思考就相对简单，但一旦投入到实际使用中，就会出现各种问题，于是会经常问我原因，比如说：做音视频的会问我，为啥他的音视频数据传输到对方的时候，会出现那么长时间的延迟、或者对方看不到本应该看到的内容呢？或者并发查看到的音视频信息为啥只有四路甚至更少呢？

搞数据库的会问我你为啥非要把原本可以直接到达数据库的业务处理复杂化呢？为什么你要在我的分布式数据库事务上又加上那么多处理信息呢？为什么你非要把和数据库连接的模块封装的能适应多种数据库呢？

做界面的会问我，这些数据怎么加密才有效呢？怎么才能放置别人对传输数据的提取和破密呢？

因为，十年来，我几乎一直都在搞通信通讯，平台架构。对于一个涉及到通信通讯的问题的考虑，我要想的比他们多，我必须要考虑单点服务器宕机风险、分布式服务器数据一致性问题、性能拐点问题、动态扩展后各个服务器协调和通知处理问题、平台融合问题等等。这些不是说仅仅是一两句话的问题。你得能设计出一些公共接口，私有结构，协调同步接口等的具体代码来，还要对每个服务器之间的关联方案和业务处理给出指导性说明文档来，架构师一个东西，不是仅画画图，说两句了之的，架构一个系统平台，你必须是考虑需求而又要跳出需求。用户需求都是一些具体的业务逻辑，而平台要一半精力关注与业务，一半精力甚至更多精力关注与稳定、性能、安全、可拓展。而这些考虑，在外人看来也无非是封装、继承、多态、重载，分布式+缓存+异步等基本圈子，又有何难？难不难，只有经验积累到一定程度或者你在这一领域一直做，摔打痛了才能体会。

正所谓不当家不知道柴米油盐贵。只要你知道了柴米油盐贵，那么你就是一个资深当家的了。当然，就平台架构方面，有比我牛逼很多的人，我也碰到过一两个，我甚至知道的任何东西，对他来说都是他的子集，那么这种人发表言论，我不会用资深来形容，我会用“大师”来形容。

本篇来说，和12306没有半毛钱关系。只是跳出一个圈，进入领一个圈来说问题罢了。另外强调一下，发帖归发帖，评论归评论，各位兄弟尽可能以技术为为出发点。

在写这篇文章的时候，想到我一仁兄很经典的话：“有时候用户只是说一句话，问一个问题，你就得写一篇文章来回应，甚至还不行。”我十分赞赏这句话，也佩服这位仁兄在处理用户需求的时候表现出的耐性和魄力。现在，我们继续上一篇的文章给定的标题的时候，发现我在这个标题上，也正在走这条路，并且已经走了很远了。

本篇我又集中于平台上了，那么这篇，我尝试从下面几点举例来说明一下一个平台架构的复杂度。还是事先声明哦，本篇和12306依然没有半毛钱关系，只是分析平台而已。

一、我对平台的定义。

这里我不想用技术性语言来表述，打算给其一个通俗的定义。

平台：即持续投入超过千万，开发周期在一年到两年，甚至两到三年，维护周期在两到三年。

做一个官网网站，考虑一天的访问量在20万左右，那根本就不需要平台，只需要架设一个网站服务器，设计好数据库的表结构以及优化好存储过程就行了，甚至于连集群和负载都不用考虑，开发周期估计2个月左右也就差不多了，这和平台差着十万八千里呢。有些人看到这里，可能开始咋舌了，这样的话，有多少家的公司才能支撑呀？很对，平台真不是一般中小公司能支撑的起来的，他们耗不起，甚至很多公司，连一个真正意义上的系统架构师都养活不了，还何谈平台？原因很简单，虽都是开发类公司，但行业不同，目标不同，目的也不同。有些仅是做网站的，有些只是致力于为客户开发软件，然后全套交付给客户的，有的是做服务运营商的，他们对于软件成型的标准显然是不同的。因此，很多公司的员工，可能在某一公司干了很多年了，属于一个公司的元老级人物，核心人物了，在公司内说话也是相当权威的，甚至在他们那个领域，那是他说了算的，但他们可能对平台依然没有概念，甚至于也没有接触过系统架构师。那当然也难以站在架构的角度考虑问题了。但你不能因为他没有平台或者架构概念或者这方面的经验，就认为他技术不行。

二、哪些是架构师要考虑的。

要想基本阐明这个问题，我想我最好还是举例说明：

用户告诉你一个需求：我想要一个文件传输功能，即能把文件从A用户发送到B用户；你会怎么考虑？

可能有人会说：那还不简单，两个客户端，使用TCP长连接，A向B发起请求，B接受请求，然后A开始读文件，每读一包就发送一包，直到B接受了整个文件，无非就是几个消息而已，有毛思考的。如果用户确实仅仅需要这么一个功能，当然用不到架构师了，一个初级程序员就能很好的解决。这也要用一个架构师来考虑的话，那只会使事情复杂化，这时候的架构师就是个屁。这样的需求，根本就不应该到架构师那里去。但是，如果这个用户需求最后真传到了架构师手里，那就不应是简单的一个需求了。现在该如何考虑这个问题呢？

首先，这是在广域网传输还是在局域网传输得考虑，到了架构师这里，对于这个需求，那肯定是广域网传输了。

其次：用什么网络传输协议，要回答这个问题，就要实先确认使用对象、使用频率、带宽以及用户传输文件的大小和需求者对这些文件的管控意愿。

在这些基本问题的牵引下，我们会想到，要想在广域网传输，就要考虑双方都处在各自处在一个不同的局域网内，他们和外网的交互是要通过一道甚至多道防火墙的，这样的话，文件传输就需要穿透这些防火墙，那我们的网络传输协议就需要考虑使用UDP，因为TCP很难或者不可能穿透这些防火墙，而UDP的穿透性就非常好（即通常所说的打洞），因此，我们自然会想到了P2P。到此，问题思考了将近五分之一了。

接着：P2P传输也不能保证一定能打洞成功呀，比如说A用户在一个公司内，B用户也在一个公司内，两个公司都可以上外网，但公司会为了确保网络安全和网络带宽资源高效利用，会把连接广域网的局域网设置的比较复杂，还会有公司网管进行监控管理，这样的话。P2P成功的几率就比较低了。因此，我们需要为解决这个问题而部署一套文件传输服务器。也即A用户和B用户通过文件传输服务器来进行文件传输。因为几乎所有广域网下的用户，都可以访问外部指定的服务器，而不会主动让外部连接主动找到你。

再接着：想到了文件传输服务器，那我们就得考虑文件传输服务器相关的内容了。如网络传输协议，这里我们会优先考虑TCP连接了。既然是服务器，免不了考虑假设很多人都要借助这个服务器来传输文件的情况，那链路个数你得控制，因为不是链路个数越多，效率就越好，效率的好坏，和带宽，单包文件传输字节数、线程个数等有直接关联的。那我们就要考虑这个用户愿意投入多大的钱来支撑带宽量了。有意愿的朋友可以这么算一下或者网上查一下，2兆带宽和4M带宽的差价，他们是倍数级关系甚至还要大，那么假如说根据用户需求，我们算出需要200M的带宽，这个价格可能就已经到了百万级别了。那用户会为了一个文件传输服务器每年耗费近百万么？所以，基于这个问题，我们得想法节省带宽，那必然要减少单包传输字节数，或者控制并发传送文件数量，那就会在效率上存在一个互为矛盾的问题。那么架构师得根据经验或者一些实际数据来找到一个最为高效的折中方案。至于要不要考虑服务器冗余备份及备份方案；很多用户传相同的文件的验证问题（这问题又涉及到文件MD5校验和秒传的问题）；文件服务器磁盘空间问题；用户文件保存时限问题等等这些必须考虑的问题，这里暂且不述了。

最后：综合了上面的思考之后，架构师得出具一个架构文档，给出每个节点模块的要求，接口，网络传输协议封装方案等等。这一切都齐了之后，还得回头来从新思考一下，在现有前提下，客户端使用哪种语言开发，服务器又使用哪种语言开发，操作系统选用哪个，给出大概的时间节点，然后把这个架构给到技术总监或者部门经理手中，技术总监或者部门经理根据拿到的东西，如何安排人手和时间，保证每个里程碑节点，那不是架构师的事情了。

至此，架构师才基本完成了一个文件传输功能的思考，而这对架构师来说，如果是给予一个平台，这只能算是一个相当相当小的模块。一个平台的复杂度。也就基本能想到了。

说到这里，我想起一个曾经的同事的话：你看架构师多自由，一个月下来，在公司呆的时间几乎不到一周，还从公司每月拿走那么那么高的工资，也没人敢记他的迟到早退。或许他根部不了解，一个架构师，为了一个平台，经常要在无人打扰的情况下思考多久，才能确保一个平台尽可能少的出现问题。而很多时候，他连个商量的人都没有，因为有多少公司，能同时样几个如此级别的人物呢？所以他得慎之又慎，考虑在考虑。要知道一旦平台存在重大缺陷。那依托于该平台的所有东西都难以进行，他承受的压力又有多少人能理解？而一旦一个平台成功了，在某个专业领域内，可以依托这个平台自由的驰骋。

三、平台的核心内容之一：分布式数据存储

只说上面那些东东，很多人还难以考虑到平台的复杂度，所以，还得从一个问题的角度，分析一下一个平台必然会遇到的处理问题：分布式数据存储。还好，这个在CSDN上有了一篇相当不错的文章了，我暂且引用一部分，这篇文章名字为《深入解析：分布式系统的事务处理经典问题及模型》我引用并修改一下如下片段：

用一台服务器来提供数据服务的时候，经常会遇到如下的两个问题：

1、一台服务器的性能不足以提供足够的能力服务于所有网络请求。

2、担心服务器宕机，造成服务不可用或是数据丢失。

面对问题,我们必须对服务器进行扩展，以及解决单点故障问题。通常，我们会通过两种手段来扩展我们的数据服务：

1、数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。

2、数据镜像：让所有的服务器数据同步，提供无差别的数据服务。

第一种方案，单台服务器出问题时，定会有部分数据丢失。所以，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储（一般工业界认为比较安全的备份数应该是3份，如：Hadoop和Dynamo）。但加入的机器越多数据就会变得越复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性。我们用最经典的Use Case：“A帐号向B帐号汇钱”来说明一下，熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作：

1. 从A帐号中把余额读出来；

2. 对A帐号做减法操作；

3. 把结果写回A帐号中；

4. 从B帐号中把余额读出来；

5. 对B帐号做加法操作；

6. 把结果写回B帐号中。

为了数据的一致性，这6件事，要么都成功做完，要么都不成功，而且这个操作的过程中，对A、B帐号的其它访问必需锁死，所谓锁死就是要排除其它的读写操作，不然会有脏数据问题，这就是事务。但是，在加入了多个机器后，这个事情会变得复杂起来：

1. 在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。在不同的机器上实现，就会比较复杂。

2. 在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作（要汇给B和C），这两个操作发生在不同的两台服务器上怎么办？也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突？

同时，还有性能因素，如不考虑性能，事务完成并不困难，系统慢一点就行了。除了考虑性能外，我们还要考虑可用性，也就是说，一台机器没了，数据不丢失，服务可由别的机器继续提供。于是，我们需要重点考虑下面的这么几个情况：

· 容灾：数据不丢、结点的Failover

· 数据的一致性：事务处理

· 性能：吞吐量、响应时间

前面说过，要解决数据不丢，只能通过数据冗余的方法，即数据副本：当出现某个节点的数据丢失时可以从副本读到，数据副本是分布式系统解决数据丢失异常的唯一手段。简单说来：
要想让数据有高可用性，就得写多份数据。

写多份的问题会导致数据一致性的问题。

· 数据一致性的问题又会引发性能问题

这就是软件开发，按下了葫芦起了瓢，当然，文章也给出了解决方案，我这里就不引用了，因为平台也是有大小的，一个千万级资金的平台，解决方案和一个上亿级资金的平台解决方案是有相当的不同的。因为每个方案的背后，都离不开资金和成本的支持。

一个资深程序员看12306相关推荐

一个资深程序员看12306 （三）
首先声明,本篇文章内容将和12306没有半毛钱关系,只是对(一)和(二)的延续. 实话说,原本是没有打算写三的,其实最初只打算写个一,因此,当时博客文章命名为<资深程序员看12306铁路售票系统 ...
一个资深程序员看12306 (二)
上一篇,我是从感官和直觉上进行的分析,可以说几乎没有涉及到技术层面. 但作为一个程序员,仅从感官和直觉上分析,那就不叫程序员了,更何况,我还自诩为资深程序员呢?尽管我一再软件行业跌打了近十年,但资深也 ...
一个资深程序员看12306(四)
在写这篇文章的时候,想到我一仁兄很经典的话:"有时候用户只是说一句话,问一个问题,你就得写一篇文章来回应,甚至还不行."我十分赞赏这句话,也佩服这位仁兄在处理用户需求的时候表现出的 ...
一个资深程序员看12306（终结篇）
"喂?老兄,今晚我请吃饭,你有时间没"? "有,当然有了." "很好,你今晚帮我值班吧!" 上面的台词估计很多人都看了都会一笑.为什么会有笑 ...
一个资深程序员成功的背后
转载:来自希赛BBS 成功的背后,有着许多不为人知的故事,而正是这些夹杂着泪水和汗水的过去,才成就了一个个走向成功的普通人. 凌晨两点半,早已习惯了一个人坐在电脑前的我,望着屏幕,任思绪在暗夜的包容下 ...
学完java后学编译原理_一个资深程序员对Java初学者的学习思维路线建议
如何学习Java,学完后尽快成为一个可以参加工作的Java开发者.现在还在待业期间,如何准备转行学习Java.相信很多初学java者都在考虑这个问题. 如果你是在校学生,务必要在学好基础(比如计算机系 ...
一个资深程序员的忠告
你是否了解,咱们中国有相当大的一部分软件公司,他们的软件开发团队都小的可怜,甚至只有1-3个人,连一个项目小组都算不上,而这样的团队却要承担一个软件公司所有的软件开发任务,在软件上线和开发的关键阶段需 ...
资深程序员参加面试因穿着被认为是新手，拿下帽子后，被当场录取
在职场上,面试几乎是每一个行业从业人员都必要要经历的过程.对于很多的职场新手来说,在面试的时候很容易因不懂"行业潜规则"而遗憾的被面试官淘汰! 最近,一个资深程序员应聘的视频引起了 ...
我是一名资深程序员，而今天我又多了一个创业者的身份（2）
我是一名资深程序员,而今天我又多了一个创业者的身份(2) 人们说:人世间四大喜事:久旱逢甘雨,他乡遇故知:洞房花烛夜,金榜挂名时.我觉得我是幸福的,在他乡朋友们因为志同道合重逢,太过于美好.午后的阳光 ...

一个资深程序员看12306

一个资深程序员看12306相关推荐

最新文章

热门文章