互联网大型应用软件架构设想与推荐

               见过很多成长中的企业，随着业务的扩大，数据流的增加，自家的软件越来越受到成长性的颈瓶，于是乎高薪招来大牛，然后就急急忙忙的乱设计架构做试验，最后搞的头痛医头，脚痛医脚的局面。

              这样的企业国内太多，多的我都不好意思说了。

              无论什么软件受到成长性的颈瓶，除了历史架构原因，没有别的因素了。

              目前解决数据流颈瓶的技术方案有很多种，我在这里仅仅做一个设想，因为不想为那种所谓的成熟方案所吸引。

              在我看来，最大的数据流软件就是google了。

              据说，google为了解决此问题，采用的硬件模块化，数据内存化（含虚拟内存技术），多进程多线程化，服务器集群化，电力集群自动化等等系列的智能处理。

              我想，如果你的软件有一天像google那么成功，那肯定会有类似的处理办法。

              我的设想是，如果你的软件在未来的五年业务增长能承受百万级并发就可以的化，那么你要做的就不是百万级并发的事，你做的事未来20年的业务增长的可控空间。

              这是一个什么样的架构设想呢（作为技术与业务并进的科技公司而言）？
              首先要考虑的是，虚拟技术，集群技术，分布式技术，其实这些代价比起购买昂贵的服务器和高速带宽强很多。

              虚拟技术其实就是将物理资源转变为逻辑上可以管理的资源，以打破物理结构之间的壁垒，想像下，任何pc都可以将计算机资源用到极致，这是一个什么概念。

              集群技术就是将虚拟技术和物理机器用到极致并突破大数据流带来的任意高并发增长，并做好网络和数据的灾备。

              分布式技术就是突破服务器资源和pc端资源的限制，同样是解决性能问题。

               目前这些技术已很成熟，现在大型企业几乎都在用或尝试这些技术解决方案。

               其次，我们要考虑是网络传输和计算机语言本身的问题。

                尽管目前带宽已很大提高，但对于一个长期发展的企业和软件来说，这是不得不考虑的事情，显然，移动端还是pc很多前端技术有了很成熟的方案，比如开源框架jquery及类jquery的数不胜数；这些框架在一定程度上解决了网络传输响应问题，其二我们要考虑缓存机制，像这里的开源框架也是数不胜数，如ehcache及类ehcache

               计算机语言的选择也是个问题，现在全球都在流行使用java，的确java是为网络而生的，有着天然的优势；但为了长远打算，除了应用业务层外使用java,  底层或中间件或应用层最好还是php+java+c+erlang这种组合方式进行，这是最有效的性能和速度及安全上的解决方案。

               服务器应用容器，有很多选择，推荐使用ngnix或was

               服务器操作系统自然不用说，linux！

               这篇文章纯属经验概述篇，今后我将陆续的推出针对性的解决方案文章。

                                                                                                                                      深圳-linux内核- 罗     2014/0711