我是2005年毕业，从毕业前的实习开始，做CAD二次开发，电气设计软件。

2006年转做无纸办公软件，那个年代无纸办公流行，C++更是主流，感觉也算有前途。

2008年转做Open Office的开发，维护世界级的产品会产生一种自豪感，Open Office本身代码体量也的确非常大。

2010年转做安全类的产品，从一个模块级负责人，核心程序员，到架构师，再到负责整体产品线的负责人，经历了4年时间。

在我的职业生涯中时不时就会产生一种莫名的危机感，经常会问自己，自己掌握的技术够深吗、是主流的技术吗、未来的职业发展又在哪里？

2006年一个同事跳槽去了一家大型企业，走的时候跟我们说，做二次开发没有前途，出去面试会被人看不起。但是我发现，在具体编码的过程中，很多经验丰富的程序员甚至不能把一个对话框程序写的很漂亮，一个对话框类的实现将界面与逻辑混在一起，没有太多解耦的思想在里面。后来的工作中悟出一个道理，没有小角色，只有小演员，只有把现在的事情做好，才能有未来。

2008年我在一个不满意的环境中，苦苦的寻找下一步的方向，从坐落在小区里的公司一直面试到了微软和IBM这个级别的公司里。被挫了很多次，也积累了很多面试的经验。其间有一家做搜索引擎的公司我没去成，我的理由只是因为工资没有任何提高。其实大家跳槽的时候都说是为了职业发展，结果往往是哪里给的条件好就去哪里，而在一般意义上看，高工资与好公司一般都是成正比的。当然偶尔也有例外，比如这里提到的做搜索的公司，如果当初在08的时候就选择做搜索引擎，也许后面的故事会很不同。

2010年我拥有了工作5年的工作经验，我发现一般工作到5年以后才会遇到一些真正的好机会。跳槽去了一家刚刚在创业板上市不久的公司，做一些安全类的产品。从这一刻开始，由于业务的快速发展和领导的信任，我开始拥有了一些能够独当一面的能力与锻炼机会。除了编写一些从无到有的模块，我开始关注架构的设计，团队培养，产品管理等一系列更宏观的问题。

回到原来的问题，我们为什么要转型，原因总结如下：

1.       大多数的程序员职业起点都偏低，很多人甚至只能从外包做起；

2.       大多数的程序员做不上主流产品，主流技术，所掌握的都是一些较为落后的技能，靠体力挣钱，而不是靠智力；

3.       很多公司不能给员工稳定的成长预期，过了某一个发展阶段双方很难找到共赢点；

4.       世界发展太快，当我们还在懵懂之时外面世界已经经历了从互联网，云计算，移动互联网，大数据，人工智能，一波又一波的产业升级。而我们一波都没赶上。

于是我们要转型。2011年当我看到hadoop权威指南这本书的时候，我感觉大数据一起会流行起来，而且大数据未来会在各行各业遍地开花。

可是，留给学习的时间真的很少，工作忙碌，下班要顾家。只好挤时间学习，在上班的路上，坐公交车、坐地铁，给小孩洗衣服，可以带着耳机听视频，成了唯一的学习方式。听视频虽然不能学到太多技术精髓，但也可以了解不少技术，开阔眼界。

2014年底，我转型做一些也数据相关的工作，做数据清洗，分析，建模，治理。我总结一下转型要做的一些事情以及要学的东西。

1.       要有行动，只停留在想法层面产生不了任何实质上的进展；

2.       挤时间，时间对于每一个认真生活的人都很宝贵，挤一下吧，少玩玩游戏啥的，总会有的；

3.       要重视学习，尤其是看书进行系统学习，从网络上看到的只言片语做为了解还行，但是不去系统掌握知识，境界很难上到新的台阶；

4.       要注视理论学习，上班以后最不缺少的就是实践，天天都在实践反而凸显的学习理论的重要性；

5.       把主要学习时间花在那些最通用、最被广泛采用的技术上，如果每天都在学习那些其他公司所不需要的领域知识时，说明该跳槽了；

6.       要注重基本的数据结构和算法，这些是写好程序的基础，基础决定高度，做那些能够解决困难问题的人，而不是做只能执行具体任务的人。差别在于能不能把现实的工程问题抽象成数据与算法。

7.       选一个好的方向，像高并发，分布式系统，数据库，大数据工具，统计建模，机器学习，数据挖掘都是即有用又缺人的领域，搞好任何一个领域都会有好的发展；

8.       我感觉能把数据分析、机器学习、自然语言处理、R语言这些学好，统计建模依然是很基础知识，不能跳跃学习；

9.       学习最重要的是入门与坚持，入门可以学视频教程，精深要靠应用与时间打磨；

就程序员的职业发展来看，我总结自己的一些经验：

1.       1~3年，要学精一门语言，这并不太难；

2.       3~5年，应该关注软件的设计，设计模式等知识

3.       5~7年，应该能独立完成一个软件模块，从需求到测试的全过程。我发现一般这个阶段会遇到一些获得期权或者股权的机会，能不能最终形成收益看运气吧；

4.       7~10年，争取可以负责更为全面的工作

在这个过程中，像数据库，操作系统，并发，多线程，项目管理，产品管理这些知识都需要，掌握的越多越好吧。

开发一个数据产品跟一个传统软件产品并没有太大的本质差异，很多技能从事哪个行业都是需要的。

我们常常会通过观摩杰作体会并学习艺术的精髓，而可扩展性也应该遵循同样的路线！

在这篇文章中，我将列出数款为大家所耳熟能详的可扩展性架构。通常情况下，架构师们完全可以借鉴已知的可扩展架构模式，进而创造出新的可扩展架构。

1. LB (负载平衡器) + 无共享单位 - 该模型中包含一系列单元，各单元彼此间不共享任何内容，且一致指向一个将输入文讯按一定条件发往单元处的负载平衡器（这构成一个循 环，以负载等情况为基础）。每个单元可以是一个单独的节点或是紧密耦合的节点所构成的集群。用户可以使用DNS循环、硬件负载平衡器或者软件负载平衡器达 成负载平衡效果。创建一套负载均衡的层次结构，并在其中结合前面提到的各种负载平衡器也是可行的。在由Michael Stonebraker撰写的《 无共享体系架构实例 》一文中，专门讨论了此类架构。
    
2. LB + 无状态节点 + 可扩展存储 - 传统的 三层式Web架构 使用的就是这种模型。该模型包括数个与可扩展存储交互的无状态节点以及一个分布于节点间负载中的负载平衡器。在这一模型中，存储通常作为限制因素存在，但NoSQL存储则可以利用这套模型创建出具备相当可扩展性的系统。
    
3. 点对点架构 (分布式Hash列表 (简称DHT)以及内容寻址网络(简称CAN)) -这套模型提供了一些传统的 可扩展算法，这些算法的各个方面几乎全部按对数进行了等比例增加。举例来说，像Chord、Pastry（特指免费版）以及CAN都属于此类。而以 Cassandra为代表的、基于P2P架构的几款NoSQL系统也是其中的成员。《 展望P2P系统中的数据 》一文就深入探讨了这类模型的各种细节。
    
4. 分布式队列 – 这种模型以将队列实施（即先进先出交付机制）作为网络服务处理为基础。该模型通过JMS队列而广泛得到采用。一般会遵循这种做法的有任务队列以及通过保持队列分级体系实现扩展性的任务队列版本，后者在负载无法及时处理时，任务会由低级层面向高级层面传递。
    
5. 发布/订阅模式 - 一般用于通过网络向彼此发布订阅讯息。《 发布与订阅的多面性 》这一经典论文中详细的介绍这一模型，该模型方面最典型的例子即 NaradaBroker与 EventJava 。
    
6. 小道消息与自然灵感式模型 - 这种模型源自日常生活中小道消息的传播途径，也就是每个节点将随机选择后续节点以交 换信息。正如现实生活中的实际反馈，这种八卦型算法在信息传播方面出奇地迅速。该模型的另一大分支则是受到生物学影响的启发式算法。自然世界中存在着大量 协调及扩展方面极为卓越的固有算法。举例来说，蚂蚁、人类以及蜜蜂等等，都能够以最简洁的交流方式协调好扩展性方面的需要。模型中的算法正是借鉴了这些实 际存在的现象。在论文《 从流行病的蔓延到分布式计算 》中对这种模型有着详尽的叙述。
    
7. 地图缩小/数据流 - 这一概念首先由谷歌公司提出，地图缩小为工作的描述及执行提供了一套可扩展的模式。虽然内容 简单，但它仍然成为联机分析处理方面的首要处理模式。数据流则是一种更先进的方式，用来表达执行信息；而像Dryad及Pig这样的项目为数据流的执行提 供了可扩展的框架。论文《 地图缩小：大型集群上的简化数据处理 》中设置了专门的主题，详细讨论这一内容。Apache的Hadoop就是这种模型的代表性产品。
    
8. 责任树形图 - 这种模型打破了递归问题的束缚，将整个流程以树状形式加以处理；每个父节点将工作下放至子节点。这种模型扩展性强，并已经被应用于数款可扩展性架构当中。
    
9. 流处理 - 这种模型被用于处理源源不断的数据流及数据。这种处理方式通过网络中的处理节点获得支持（例如Aurora、Twitter Strom以及Apache S4等）。
    
10. 可扩展存储 – 该模型的应用范围从数据库、NoSQL存储、服务注册到文件系统都有体现。 链接中的这篇文章 以可扩展性为切入点对其进行了深入讨论。

综上所述，可扩展性的实现只有三种方式，即：分布、缓存及异步处理。前文所提到的各种架构事实上都是把这三种方式进行不同组合并加以实施。而另一方 面，不利于可扩展性的因素，除了糟糕的编码本身，全局性协调也起到了重要的影响。简单来说，任何一种全局性协调都会限制系统的可扩展性。本文中所提到的各 种架构也只是在做好了本地性协调，而非全局性协调。

然而，将它们有机地结合起来以创建一套极具可扩展性的架构可不像说起来那么容易，除非我们能找到一种全新的扩展模式。不过经验告诉我们，比起搞一套全新的架构，采用为我们所熟知且更易驾驭的可扩展性解决方案永远是更好的选择。

1、 高峰时段无法登陆，提示在线用户过多

2、 订单提交成功之后，支付环节出了问题，浏览器意外退出，后再登陆，发现登陆不上，无法在规定时间内完成支付，购票失败

3、 订单提交反馈时间过长，热门线路需要等待20分钟甚至更长时间，才能得到反馈

4、 验证码输入总是错误，无法完成验证码验证环节，无法登陆

5、 逢用户高峰，网站反应速度较慢

6、 对多浏览器支持不好，没有IOS，Android应用入口

以上问题多数都是用户体验的问题，用户体验的问题即有票源稀少的原因，更多的是对订票系统使用过程中系统登陆困难，反应迟钝，订单结果反馈太慢，意外退出等问题难以忍受。

本人并非订票系统设计人员，但是通用对订票系统外在的表现大胆猜测一下订票系统的设计。

常见问题原因分析：

问题1，高峰时段无法登陆，提示在线用户过多；

问题4，验证码输入总是错误，无法完成验证码验证环节，无法登陆

无法登陆的问题，其原因显然是前端用于处理WEB连接服务器太少或网络带宽不足所至，为了不让更多的用户一起连接服务器导致服务器较慢，只好拒绝一些用户的登陆请求。使同时在线人数保持在一个上限以内。

验证码输入总是错误的问题，原因也是用于处理WEB连接服务器太少所至，为了防止一些客户端使用“恶意”软件，不断自动登陆的情况，验证码需求由客户端向服务器提交一个验证请求，可以由于服务器响应实在太慢，以至于整个响应速度居然超过了验证码的有效时间。

常见问题：

问题2：订单提交成功之后，支付环节出了问题，浏览器意外退出，后再登陆，发现登陆不上，无法在规定时间内完成支付，购票失败

问题3：订单提交反馈时间过长，热门线路需要等待20分钟甚至更长时间，才能得到反馈

问题5：逢用户高峰，网站反应速度较慢

问题2是一个系统的BUG，但是可以通过一些设计来解决这个问题。

问题3，问题5，可能是由于WEB服务器与逻辑处理服务器在同一台机器上，而导致服务器CPU分配了过多的时间与资源在处理用户请求，在执行逻辑时执行缓慢。

如果数据库也在同一台服务器上，那问题可能更加严重。当然我相信，不在一台服务器上的可能性比较大。

总结以上问题，其解决方案建议如下：

1、 准备更多前端WEB服务器，解决WEB前端的问题没有别的办法，只能加服务器，或者每个省市放一群单独的服务器，根据用户量进行增加，直到响应流畅为止。

2、 可以考虑把逻辑服务器单独分离出来，与WEB服务器分开，WEB服务器只处理WEB请求，逻辑服务器单独运行

3、 把数据库服务器单独分离，并且把火车票票量数据库与用户订票信息数据库放到不同的机器上，由于大量的订票请求会访问火车票票量数据库，并且会有大量订票数据添加到用户订票信息数据库中，在处理添加的逻辑占用了大量的数据库资源，会导致整个系统变慢。如果放到同一台机器上，必然导致响应变慢。把不同性质的数据，放到不同机器、不同的数据系统中，可以合理的分流系统访问量，使系统响应加快，横向扩展更具有弹性。

4、 把支付订票费用放到一个单独的网站进行，订单提交成功后锁票，之后根据订单号可以在另外一个单独的网站上进行单独支付，支付时只要提供订票号就可以，这样做有很多好处：1. 避免了由于支付失败而导致退出浏览器，却由于在线人数过多无法登陆导致订票失败的情况，2. 电话订票也可以在此支付，在火车站机自动售票机器上取票，这样支付方便，也解决了异地付款取票的问题 3. 单独支付会在一定程度上给订票网站减轻访问与处理压力

5、 提供快递火车票服务进行创收，支付成功的火车票可以进行快递，这样即方便订票人也可以给铁道部创收

6、 网站可以根据用户订票信息做一些有针对性网站广告，如旅游、酒店广告等进行创收

7、 开发出更多的手机终端软件，扩大订票系统使用的覆盖面

8、 支持更多的浏览器，而不仅仅是IE

由于本人水平有限，欢迎各个高手批评指正，希望这篇文章能够抛砖引玉，大家一起讨论。
网上的其他类似文章：

http://cloud.it168.com/a2012/0130/1304/000001304533.shtml