从0开始搭建Web架构

架构总图


接下来进入正题，首先看这张总图：

从0开始搭建Web架构
 


网络接入层


 


1防火墙


全部的访问请求(企业内部访问可能除外)都是要通过企业级的防火墙设备。不论是企业自身的机房仍是托管的IDC机房，通常最外层都是由防火墙把关全部访问请求。对于一些恶意的木马植入等，防火墙会抵挡住大部分。做为Web架构，最外层必定要选好防火墙，并且防火墙的架构最低通常会选择不一样型号的两台。


2安全设备


防火墙以后会接入IPS(入侵防护系统)，WAF(Web应用防御系统)。这一块区域主要对网络安全，系统安全作检测和防御的，能够采用商业设备(推荐)，资金不足的企业也能够采用开源设备，这里推荐一款开源产品OSSIM，有兴趣的同窗能够了解一下。


3负载均衡


通过网络安全防御以后，接下来是咱们的硬负载设备（该层无关紧要），通常硬负载均衡设备主要有F5，A10，相对比较贵，企业能够根据状况选择。


硬负载接下来通常会有一层软负载(固然软负载和硬负载能够只留一种也能够都有)。软负载层通常也会部署反向代理服务器，用做反向代理，也起到了防御安全的做用。


通常在网络规划上，该层位于DMZ区域，该层之下的服务器位于内网。这块隔离了外部请求和内网的直接交互，安全上有所提升。通常该层的技术选择有Nginx，Apache，Haproxy，LVS等。大部分应该是一Nginx居多，既能够作负载均衡，也能够作反向代理，而且相对而言高并发效率更好。


关于这几者的区别，网上也有不少，有兴趣的同窗能够多多比较。其中说明一点的是LVS是工做在网络4层之上仅做分发之用，没有流量的产生，其余三种是工做在7层之上，若是不适用硬负载设备的话，建议使用LVS做为流量转发的负载设备，而后再是Nginx或是Haproxy。Apache在一些传统企业存在或是使用得比较多，也比较稳定。


前端架构


 


通常在负载均衡后面是挂载的各类各样的应用服务器。在部署应用服务器的时候通常会将静态资源（JS，CSS，图片，文件）等单独一台服务器部署，以减轻应用服务器的带宽和IO，提升访问效率。将这些静态资源部署在静态资源服务器、文件服务器、图片服务器等。通常地若是咱们有CDN，会将这些静态资源放在CDN上以提升网络加载速度。常见的文件服务器和图片服务器的技术架构有FastDFS，MogileFS，GraphicsMagick等。


可是中小企业建议直接购买云服务。一是能够减小运维成本，二是能够提升访问的速度，通常云服务都搭配CDN。本身搭建文件或图片服务器的运维成本仍是比较高，对技术要求也比较深刻。这里你们在架构的时候须要仔细考虑好。


应用服务器


 


1web应用服务器


应用服务器通常是tomcat，IIS，resin等。通常有一个应用视状况会有多台服务器(最少2台)，应用之间要解耦，应用之间的依赖尽可能采用接口交互（尽可能避免数据库方面dblink等方式）。各位在作应用系统解耦的时候能够参考如今比较流行的服务化，微服务等技术架构如dubbox等，可是须要对开发有必定的了解。虽然咱们的团队经历过和正在作dubbox的服务化，可是本人参与不是不少，因此也但愿可以向你们多学习。


2消息队列服务器


增长消息队列服务器有如下几点好处：


1.因为消息队列服务器的速度远高于数据库，可以快速处理并返回数据；
2.消息队列服务器具备更好的扩展性；
3.在高并发的状况下，延迟写入数据库，能够有效下降数据库的压力。


消息队列常常用在高并发应用（如抢购），不一样系统模块间高速数据交互等。经常使用的消息队列技术有ActiveMQ，RabbitMQ等，这些技术自己就有很好的集群或是主备机制，而且有监控的页面，很是方便快速扩展和使用。监控在使用的时候，通常须要脚本(CURL获取监控页面的值和监控页面的http staus)或其余方式监控，实现故障自动告警。


3缓存服务器


数据缓存服务器，常有的部署有Memcached，Redis等，目前应该是以Redis居多吧。另外应用应用服务器集群的session问题也经常用到Redis。Redis自身的哨兵模式，集群Cluster(3.0以上版本支持)能够避免单点故障，方便横向和纵向扩展，缓存热点数据提升访问效率，在高并发环境也是常常用到的技术。


这里要注意一下，并非全部的Web架构都须要消息队列或是数据库缓存，视状况而定，根据系统的并发量和访问量评估。合适本身的才是最好的。


数据库层


 


1数据库链接池


应用跟数据库之间通常要尽可能避免应用直接链接数据库，采用数据库链接池的方式。数据库链接池技术带来的优点有资源复用、更快的相应速度、统一的链接管理、避免链接泄露等好处。经常使用的有c3p0,dbcp,druid等，这里强烈推荐Druid。


2数据库架构


数据库链接池后面就是数据库了。数据库种类也比较多，经常使用的有Oracle，MySQL等。固然了，一个系统使用一套数据库，尽可能避免多套应用系统使用同一个数据库。


因为数据库的重要性，须要考虑到数据库方案。包括实现数据库的高可用、负载均衡等，有些电商平台还须要实现读写分离，数据库的横向纵向拆分等，以实现复杂的数据库应用。


Oracle的经常使用架构有RAC，DG(dataguard)，而Oracle的成本比较高，因此不少中小企业会选择MySQL。MySQL也有不一样的分支和技术方案，如官方版本的MariaDB，PerconaDB等。经常使用的高可用架构有复制，Cluster，不一样分支都有支持，这里我推荐你们使用MariaDB10.0以上的版本，效率相对较高。


MySQL的中间件也比较多，用来支持负载均衡，读写分离，分库分表等。如OneProxy，MyCAT等都是很是优秀的MySQL数据库中间件，建议你们有时间多研究，架构出稳定可靠的数据库集群。


数据库的备份和恢复这里就不单独说了，在下面的灾备方案中统一说明。


3存储设备


通常企业会有专业的存储设备。存储设备的raid选择、主备架构方案等都须要提早架构以及跟存储厂商沟通讨论。做为最关键的设备之一，必定要避免单点故障，不然将致使整个IT系统宕机。


以上是关于常见的Web系统架构的一个概述，以及经常使用的一些技术方案的说明，有不足之处，请你们多多指教，相互学习。


灾备方案


接下来跟你们介绍关于备份相关的问题。无论传统企业仍是互联网，备份必定是一个及其关键重要的工做。没有备份，就意味着系统没有最基本的保障。


常见的灾备方案通常是同城热备，异地灾备的方式，即两地三中心的方式。同城的网络延迟通常能够作到比较小，因此在用实时热备的方式是可行的。将应用服务器、数据库等经过实时同步的方式，数据传输到同城其余机房，实现跨机房的热备。


异地采用延迟备份的方式。将本地机房的备份集经过网络传输传送一份到异地机房实现异地灾备。其中异地灾备是有数据延迟的，通常一天。


不论是应用服务器，仍是数据备份的方式都有不少种，因时间限制就不一一跟你们分享了。这里要着重注意的是备份集的测试方案，必定要与灾备方案一块儿，并根据测试方案严格定时执行，确保备份集的准确性。


其余方面


做为一套完整的IT技术架构方案，其实还有不少方面须要考虑，例如监控方案。咱们经常使用的监控方案有lepus监控数据库、Zabbix、脚本三者结合的方式。经过邮件，阿里大于短信等方式发送报警，日志服务器用于采集和分析日志，如ELK等。还有通常企业会有数据平台用于分析本身数据，这里能够参考个人另外一篇文章《数据即金钱，中小企业如何搭建数据平台分得一杯羹？》


另一般企业为了节省成本会考虑虚拟化，将服务器等硬件资源虚拟化，提升利用率节省企业的成本，进而为企业的私有云搭建奠基基础。之后但愿有机会跟你们一块儿交流虚拟化+私有云的技术方案，这也是咱们如今正在着手进行的，颇有实践参考意义。


关于互联网创业初期技术团队


上面这些是关于技术方面的架构，接下来的时间简单分享一下关于技术团队初创期间的一些经验教训和想法，欢迎拍砖。


主要如下几点：


1.以核心业务为中心，初期技术团队不断知足业务需求。避免盲目扩张团队规模和采用过于超强的技术架构，技术架构要匹配业务发展的需求和规模。
2.建议初期之外包为主，可是核心业务和技术架构必须以本身团队的人为主且不能动摇。要有外包项目结束后能迅速接手的能力。
3.团队要小而精，扁平化管理，少管理岗，多技术岗，团队要有共同的目标和发展愿景。


传统企业转型互联网尤为要注意，纵使财大气粗，也要精打细算。就我的而言，经历过IT团队短短一年左右的时间从13人到200多号人，业务规划却迟迟没有突破的状况，最终大批裁人，拼命挣扎的一种状态。


友情提醒一下各位，当注意到团队成员工做并不饱和，但同一岗位还有招聘计划时，必定要考虑一下是该招聘仍是该减员。


纵观一批批倒下的初创公司，失败的经验教训很值得咱们深刻研究和学习。