BAT解密（3）：一张图概括互联公司的
大部分人对BAT的技术有一种莫名的崇拜感，觉得只有非常牛逼和天才才能做出现在的这些系统，但经过前面两篇博文的分析，我们可以看到其实并没有甚么神秘的气力和魔力融会在技术里面，而是业务的不断发展推动技术的不断发展，一步一个脚印，延续几年乃至10几年的发展，才能到达当前技术复杂度、先进性、牛逼度。
BAT解密（1）：聊聊技术发展的驱动力
BAT解密（2）：聊聊业务如何驱动技术发展
抛开BAT各自差异很大的业务，站在技术的角度来看，其实BAT的技术架构基本是一样的，再将视角放大，你会发现全部互联行业的技术发展，最后都是殊途同归。
如果你正处于一个创业公司，或正在成为另一个BAT的路上而拼搏，那末深入理解这类技术模式（或叫技术结构、技术架构），对自己的发展、公司的发展都大有裨益，你将不会再迷茫，你也不再会心里打鼓，CTO将对你刮目相看，CEO将奉你为神明：）
闲话不多说，有图有真相，看看互联的标准技术架构是什么模样：
上面这张图基本上一打尽了互联技术公司的技术点，不同的公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。
接下来我将逐一介绍每一个技术点，包括为何会有这些技术点，这些技术点的主要场景是什么，这些技术点将如何发展。
存储层技术剖析L
即关系数据。前几年NoSQL火了一阵子，很多人都理解为NoSQL是完全抛弃关系数据，全部采取非关系型数据，但事实经过几年的实验后，大家发现关系数据不可能完全抛弃，NoSQL不是NoSQL，而是NotOnlySQL，即NoSQL是SQL的补充。
所以互联行业也必须依赖关系数据，考虑到Oracle太贵，还需要专人保护，一般情况下互联行业都是用MySQL、PostgreSQL这类开源数据库。这类数据库的特点是开源免费，拿来就用；但缺点是性能相比商业数据库要差较多。随着互联业务的发展，性能要求愈来愈高，必定要面对一个问题：将数据拆分到多个数据库实例才能满足业务的性能需求（其实Oracle也一样，只是时间早晚的问题）。
数据库拆分满足了性能的要求，但带来了复杂度的问题：数据如何拆分、数据如何组合。这个复杂度的问题解决起来并不是那末容易，如果每一个业务都去实现1遍，重复造轮子将致使投入浪费、效力下降，业务开发想快都快不起来。
所以互联公司流行的做法是发展到一定阶段后，就会将这部份功能独立成中间件，例如百度的DBProxy、淘宝的TDDL。不过这部份的要求很高，将分库分表做到自动化和平台化，不是一件容易的事情，所以一般是很牛逼的公司才会做。典型的有：百度的DBProxy、淘宝TDDL。
以下是淘宝TDDL的结构图（来自果壳）：
SQL
NoSQL首先体现在数据结构上与传统的SQL的不同，例如典型的Memcached的Key-value结构、Redis的复杂数据结构、MongoDB的文档数据结构；其次NoSQL无一例外的都会将性能作为自己的1大买点。
NoSQL的这两个特点很好的弥补了关系数据库的不足，因此在互联行业NoSQL的运用基本上是基础要求，要是你听到一个号称自己是互联公司却连NoSQL都没用，那基本上可以判断是挂羊头卖狗肉类型的。
由于NoSQL方案一般都会自己本身就提供集群的功能，例如Memcached的一致性hash集群、Redis3.0的集群，因此NoSQL在刚开始运用的时候很方便，不像SQL分库分表那末复杂。一般公司也不会在开始的时候就斟酌将NoSQL包装成存储平台，但如果公司发展很大，例如Memcached的节点有上千乃至几千的时候，NoSQL集群就很有意义了：首先是集中管理能够大大提升运维效力；其次是集中管理可以大大提升资源利用效力，台机器，如果利用率能提升10%，就是减少台机器，一年几十万就节省出来了。
所以，NoSQL发展到一定范围后，一般都是走集群线路，固然要发展到这个阶段，一般也是很牛逼的公司才会这么做。
典型的有：Twitter的Twemproxy，豆瓣的BeansDB、腾讯TTC。
以下是Twemproxy的结构图：
3.小文件存储
除关系型的业务数据外，互联行业还有很多用于展现的数据，例如淘宝的商品图片、商品描写；Facebook的用户图片，新浪微博的一条微博内容等等。这些数据具有3个典型特点：1是数据小，一般在1M一下；2是数量巨大，Facebook年就到达了每天上传3.5亿张的照片；3是访问量巨大，Facebook每天的访问量超过10亿。
由于互联行业基本上每一个业务都会有大量的小数据，如果每一个业务都自己去斟酌如何设计海量存储和海量访问，效力自然会低，重复造轮子，投入浪费，自然而然的想法就是将小文件存储做成统一的和业务无关的平台。
和SQL和NoSQL不同的是，小文件存储不一定需要公司或业务范围很大，基本上可以认为业务在起步阶段就可以斟酌做小文件统一存储。得益于开源运动的发展和最近几年大数据的火爆，在开源方案的基础上封装一个小文件存储平台并不是太难的事情。例如HBase、Hadoop、Hypertable、FastDFS等都可以作为小文件存储的底层平台，只需要在这些开源方案3再包装一下基本上就可以用了。
典型的有：淘宝的TFS、京东JFS、Facebook的Haystack。
以下是淘宝TFS的架构：
开发层技术剖析1.开发框架
在系列文章的第2篇《BAT解密：业务如何驱动技术发展》中我们深入分析了互联业务发展的一个特点：复杂性愈来愈高。复杂性增加的典型现象就是系统愈来愈多，不同的系统由不同的小组开发。如果每一个小组用不同的开发框架和技术，将会带来很多问题，典型的问题有：
技术人员之间没有共同的技术语言，交换合作少
每类技术都需要投入大量的人力和资源和熟练精通
不同团队之间人员没法快速活动，人力资源不能高效的利用
所以，互联公司都会指定一个大的技术方向，然后使用统一的开发框架，例如Java相干的开发框架SSH、SpringMVC、Play、Ruby的RubyonRails、PHP的ThinkPHP、Python的Django等等。使用统一的开发框架能够解决上面提到的各种问题，大大提升组织和团队的开发效力。
对框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术！为何呢？
首先，成熟的框架资料文档齐备，各种坑基本上都有人踩过了，遇到问题很容易通过搜索解决
其次，成熟的框架受众更广，招聘时更加容易招聘到适合的人材
第三，成熟的框架更加稳定，不会出现大的变动，合适长时间发展
以我亲身经历的一个反例为例：我们使用了Play1作为Java开发框架，由于它是轻量级的Java开发框架，但没想到Play2直接改成Scala语言开发，Play1的架构演进停滞，而我们又不能切换为Play2，结果就致使只能一直用Play1，有新的需求只能自己开发。
2.服务器
开发框架只是负责完成业务功能的开发，真正能够运行起来，给用户提供服务，还需要服务器配合。
独立开发一个成熟的web服务器，本钱非常高；且业界又有那么多成熟的开源web服务器，所以互联行业基本上都是拿来主义，挑选一个流行的开源服务器便可。牛逼一点的公司，可能会在开源服务器的基础上，结合自己的业务特点做二次开发，例如淘宝的Tengine，但一般公司基本上只需要将开源服务器摸透，优化一下参数，调剂一下配置就差不多了。
选择一个服务器主要和开发语言相干，例如：Java的有Tomcat、Jboss、Resin等，PHP/Python的用Nginx，固然最保险的就是用Apache了，甚么语言都支持。
有的人可能担心Apache的性能之类的问题，其实不用过早担心这个，等到你的业务真的发展到Apache撑不住的时候再斟酌切换也可以，那时候你有的是钱，有的是人，有的是时间。
3.容器
容器是最近几年年才开始火起来的，其中以Docker为代表，在BAT级别的公司已有较多的运用，例如腾讯：腾讯万台范围的Docker运用实践；新浪微博：微博红包：大规模Docker集群实践经验分享等等。
传统的虚拟化技术是虚拟机，解决了跨平台的问题，但由于虚拟机太庞大，启动慢，运行时太占资源，在互联行业并没有大规模的运用；而Docker的容器技术，虽然没有跨平台，但启动快，几乎不占资源，推出后立刻就火起来了，预计Docker类的容器技术将是技术发展的主流方向。
千万不要以为Docker只是一个虚拟化或容器技术，它将在很大程度上改变我们目前的技术情势：
运维方式会产生革命性的变化：Docker启动快，几乎不占资源，随时启动和停止，基于Docker打造自动化运维、智能化运维将成为主流方式
设计模式会产生本质化的变化：启动一个新的容器实例代价如此低，将鼓励设计思路朝“微服务”的方向发展。
例如一个传统的站包括登录注册、页面访问、搜索等功能，没有用容器的情况下，除非有特别大的访问量，否则这些功能开始时都是集成在一个系统里面的；有了容器技术后，一开始设计就可以将这些功能依照服务的方式设计，避免后续访问量增大时又要重构系统。
精彩推荐数据的价值成为各大公司追逐的目标，如何更加有效的利用大数据创造价值呢？LinkedIn、Twitter、Cloudera、阿里巴巴的一线技术专家将为大家诠释，带你看尽技术的繁华更替，详情
北京中科白癜风医院北京中科忽悠