提纲

[]产品[/][]技术[/][]数据[/][]运维[/]

创业

核心:以产品为核心

团队人数:初创团队人数控制在10人以下,最佳是5,6人左右 

技术选型:成熟技术,简洁高效解决问题 

目标:快速完成beta 版本上线

产品中心

[list=1][]Axure做产品原型；[/][]直接画草图 [/]

一切以简单为指标,能说明问题就行。

语言框架

[list=1][]linux+apache(nginx)+mysql+php(CodeIgniter ,Symfony...) [/][]uwsgi+python(Django,Tornado,Pyramid...) [/][]mongodb+nodejs(Express...)[/][]java[/]

十万级PV

二台机器部署系统，传统web系统,LAMP。

百万PV

移动系统问题

[list=1][]与传统web相比,移动出现多版本(1.0,2.0,3.0...),以及版本升级问题[/][]网络不稳定(3g,wifi)[/]

开源软件

负载均衡:lvs、haproxy、nginx

前端缓存代理:squid、varnish、ATS

web server :apache、nginx、Tomcat

cache:memcached、redis 

关系型数据库:mysql、postgresql 

文档型数据库:mongodb 

nosql:Tokyo Cabinet、leveldb

全文检索:sphinx、lucene、solr 

分布式搜索引擎:elasticsearch 

中文分词:mmseg、ictclas

爬虫采集:scrapy

监控系统:nagios、cacti、zabbix 、Ganglia

推荐系统:mahout

消息队列:: zeroMQ、RabbitMQ、Kafka

异步作业队列:gearman 

分布式文件系统:fastdfs、moosefs 

项目管理:JIRA

知识共享：wiki、Confluence

代码管理:git、svn

移动统计数据:countly 

分布式计算存储:mapreduce、hadoop

还有好多好多，就不一一介绍了！

移动初始架构

统计数据可视化和推荐系统

监控

架构感悟

[list=1][]没有一层不变的架构,随着业务发展而变化 [/][]业务不同,架构不同,发现问题解决问题 [/][]保持简洁[/][]易于扩展,容错[/]

TCP(Transmission Control Protocol)传输控制协议

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

Sequence number(顺序号码) Acknowledge number(确认号码)

[]第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；[/][]第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包[/][]第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。[/][]完成三次握手，主机A与主机B开始传送数据。[/]

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 

[]第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认； [/][]第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器 进入SYN_RECV状态； [/][]第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。 [/][]完成三次握手，客户端与服务器开始传送数据.[/]

实例

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

[]第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;[/][]第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;[/][]第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。[/]

图解

一次三次握手的过程（图1，图2） 第一次握手的标志位（图3）我们可以看到标志位里面只有个同步位，也就是在做请求(SYN) 第二次握手的标志位（图4）我们可以看到标志位里面有个确认位和同步位，也就是在做应答(SYN + ACK) 第三次握手的标志位（图5）我们可以看到标志位里面只有个确认位，也就是再做再次确认(ACK) 一个完整的三次握手也就是 请求---应答---再次确认  四次分手：

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

[]（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。[/][]（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。[/][]（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。[/][]（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）[/]

状态详解：

CLOSED：这个没什么好说的了，表示初始状态。

LISTEN：这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。

SYN_RCVD： 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。

SYN_SENT： 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。

ESTABLISHED：这个容易理解了，表示连接已经建立了。

FIN_WAIT_1：这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。

FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。

TIME_WAIT： 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。

CLOSING： 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

CLOSE_WAIT： 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。

LAST_ACK：这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。

总结

Q：为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

A：这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的.

Q：为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

A：这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

顾客就是上帝

传统的行业IT架构实现“云”化的过程多是基于现有业务系统采用为虚拟化，并辅之以资源池化等措施，渐渐构建为一个完整的私有云系统。由于各行业的业务系统差异较大，私有云落地过程中总会遇到这样那样的问题。作为一个技术人，将从私有云在典型行业的典型部门中落地的过程中，简述厂商在虚拟化方面很有可能遇到的痛点。

政务

政企中的桌面按职能划分包括办公、财务等，而这些正是桌面云的期望场景。加之目前国内政企在一些关键项目上非常乐意采用国内虚拟化产品，这也就给国内的IT厂商带来了机遇。

场景分析：

政企中的私有云，尤其是虚拟化部分近些年来一直在进行尝试性地推广。下面我以需求最直接的桌面云进行叙述。

用户桌面：

面向办公的桌面，一般需求为Mircosoft Office、邮件处理等文字密集型软件；通信类软件一般为国内厂商开发的非广域网通信软件以及QQ；防病毒软件种类比较多，目前卡巴斯基、诺顿等占 多，360使用较少；影音类软件使用局限于网页flash，或者国内厂商定制的流媒体客户端。

对于财务桌面，需求除普通办公桌面外也有一些财务类软件，而这些软件对桌面负荷较普通办公桌面会高出一定量的资源消耗，同时也会有U-Key、指纹 仪等终端设备，所以对于这类桌面，我们一般进行特殊设置，比如将其固定到某台服务器上运行，并赋予一定优先级，保证资源优先分配。

在普通桌面与财务桌面以外，也有浮动桌面可供出差人员或者来访人员临时使用，此种桌面与一般办公桌面无异，但可能要求有严格的用户检查控制以及无状态模式要求，防止恶意使用导致损失。

系统维护：

政企中的网络管理人员一般为具有一定计算机水平的专业人士，并且他们在部门里推广办公桌面的时候起着很重要的作用。所以我们首先获得他们对产品的认可，解决他们在现有架构中遇到的管理困难。 不管在哪种场景中，管理人员对产品的认可，都是产品价值的体现之一 。

安全保障：

政务IT系统中的安全模块在系统的每个层次里都有体现，包括桌面、网络、交换设备、服务器、操作系统等，同时也可能会与其他基础设备连接，每个模块 相对独立又保持联系。一般在涉及安全的场景中，我们会采取服务端镜像加密和其他一系列的安全保障工作，兼顾性能和安全的同时保证桌面体验，这点在以后的章 节中会有所阐述。

虚拟化融合架构：

物理机与虚拟机同时提供服务的模式已经不是什么新东西了，早些年就已经有一大批使用虚拟服务器的政企客户，但涉及的产品基本以国外产品为主。随着国 产化的一系列强制措施和美国对华的服务器CPU的禁售，国产品牌才开始崭露头角。在一些服务器消耗量比较大的政企客户中，也渐渐地在周边业务系统上使用国 产虚拟化产品。我相信在未来几年内，国内虚拟化厂商会在政务云的服务器虚拟化中会占有很大比例，并且是不可替代的重要组成。

痛点----->文件监控：

谈政务云，多数标书中都会提到的一点就是文件监控。一般虚拟化厂商在这方面积累较少，使用fs-notify去开发有一定开发量，所以多数人会使用 第三方产品进行集成。国内常用的文件监控方法即使用Windows文件系统事件通知机制，软件相对比较成熟，在此我就不一一推荐了。那么，既然有现成的 解决方案，那么我为什么要把它列为虚拟化软件的痛点呢？

从我的使用经验来看，主要有以下原因：

技术方面：此类软件一般不止监控文件读写、目录读写、重命名、拷贝，同时也会进行磁盘扫描，而这点，对于用于桌面云的增量磁盘来说是比较高的IOPS负载。对于一台12盘位的15K SAS机械硬盘存储设备，最多能扛住40到70台虚拟机同时扫描（数据来自某国产存储）。

销售方面：标书中有时会提到“上述功能需来自同一厂商提供”，这就需要虚拟化厂商有一定实力，传统监控软件厂商才会与之合作为其定制，而这点对于现 在雨后春笋般的虚拟化厂商而言，正是痛处——目前国内各家虚拟化系统差异化严重，导致传统厂商为虚拟化定制的成本相对会比较高，而不愿意为国内中小厂商定 制了。目前这一状况随着国内市场的虚拟化推进正有所改善。

痛点----->权限管理：

政务中的权限管理包括：虚拟机控制权限管理、桌面软件安装权限管理、文件权限管理，对于开源虚拟化厂商而言，只有虚拟机控制权限自己可以控制，桌面 软件安装权限管理可以借助Windows AD来进行管理，当然需要一定开发量，而较细颗粒的文件权限管理则一样需要借助第三方。

同文件监控一样，但是它一般不会进行后台文件扫描，但技术上要求是要和虚拟化紧耦合的状态，用某次客户交流的原话，“你最好界面里有一个控制台，我可以看到虚拟机里的Word文档，同时我也可以控制哪些人访问哪些文件”

目前来说，这类权限管理软件可以配合集中/分布式存储软件（云存储），一般虚拟化厂商要在开源云存储的基础上进行大量修改才能达到国内政企客户的基本要求。目前国内有许多私有网盘厂商做的都不错，但是比较缺少它们和虚拟化厂商深度合作的案例。

总结：

政务私有桌面项目中，对桌面“虚拟化”的概念不是很有需求，除非有特别文件下发，即使下发后，客户还是倾向于按照传统的那一套路来。如果要在这个行业中产生影响，建议与传统软件厂商合作，一起发力。

教育

教育行业是目前国内大多数虚拟化厂商都在发力的市场，而这方面做的比较好的厂商有两类。一类是专注教育行业数十年乃至更长的传统软件厂商，他们拥有难以复制的经验，其私有云产品往往会弱化“虚拟化”概念，有强烈的“传统”色彩；还有就是专注教育行业的新厂商，他们的对教育行业的需求定位是从私有云的特性考虑，在解决问题的同时也能够将新理念传达至客户。

学校对于虚拟桌面的需求近几年开始增长，教学机房、服务器机房、教师电脑等都有虚拟化产品的进入。而他们在虚拟化产品的采购上，关心桌面体验与服务器性能的同时，也比较在乎“成本”的问题。

场景分析：
通用教学云模型 

用户桌面：

学校中使用的桌面，一般可分为教师办公桌面和机房教学桌面。

教师桌面即普通办公桌面，主要用途即为老师提供日常办公软件，一般无特殊要求。

对于机房教学桌面，有安装软件繁多、使用时间固定、并发量大等特点，比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外，也包括各种文字、图形密集类教学软件，同时也可能会安装影音广播教学类软件。无特殊要求外，很少安装杀毒软件。

系统管理：

对于机房教学桌面，有安装软件繁多、使用时间固定、并发量大等特点，比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外，也包括各种文字、图形密集类教学软件，同时也可能会安装影音广播教学类软件。无特殊要求外，很少安装杀毒软件。

安全保障：

教学环境中的安全要求一般比较低，除了常见的流量安全管理软件外，很少有桌面级监控软件。每个老师的桌面一般由管理员定期提醒查杀，主要维护工作还是由各个老师来做。

痛点----->多媒体教学：

那么对于进入教育行业的国内虚拟化厂商，可能都会遇到一个新旧交替环境中必须面对的问题——多媒体广播教学。

传统教学机房使用多媒体广播卡或者广播教学软件来进行教学。多媒体广播卡即是在学生机、教师机上安装的硬件，广播时将教师端桌面转化后直接覆盖学生机的VGA信号，此时使用虚拟桌面并不影响广播体验，但是采用纯软件的多媒体教学系统时情况就有所不同了。这类软件进行视频广播时，默认会利用本地显卡的硬解能力，而一般虚拟化产品中并没有符合要求的模拟GPU硬件支持，所以会带来体验上的硬伤。不过比较喜人的是，这些厂商已经意识到这个问题，开始在其广播教学软件中加入了软解选项从而改善体验。

还有就是在语音质量要求比较高的教学环境中，虚拟化厂商有时也会遭遇意外。语音质量的好坏，除了网络环境外，教学软件、虚拟化软件也有一定影响。在某次测试项目中，公司网络环境下的虚拟桌面语音很流畅、延迟极低，但是到客户机房后，就出现了杂音，声音小等问题。后来我们尝试优化协议、简化虚拟桌面网络拓扑，然后才取得令人满意的效果；

多说一点，在呼叫中心（VoIP、传统PBX）这种语音传输质量要求极高的场景中，有时必须特定硬件配合才能完成虚拟桌面中语音的流畅。

痛点----->3D教学：

对于设计专业、工科专业来说，3D设计、3D模拟、3D建模都是很平常的科目，而这类软件采用学生机本地独显能很好地处理，但是到了虚拟化产品中就是整个开源虚拟化头疼的问题了。一般这种情况下，开源软件从技术上的处理方法可能不如闭源软件（Citrix、PCoIP、RDP RemoteFX）来的稳妥。

由于它涉及到桌面协议、模拟器、GPU等相关知识，所以其开发难度较大，国内私有云厂商在未与GPU提供商合作的前提下很难在点有所突破。

常见设计类软件比如Adobe Fireworks，在虚拟桌面中我们将“显示渲染”设置为“软件”，能够比较流畅的拖动、显示模型，但是此时会占用大量带宽，原生Spice协议此时甚至维持在20MBps，对于拥有几十台教学机的机房而言这点是不可接受的。另一种妥协的解决方式是采用RDP，带宽能降到10MBps，但是使用场景就被大大限制了。

目前，国内这些3D教学类的项目，采用Citrix的多于VMWare，也有人使用Hyper-V，而极少有国内厂商提供KVM虚拟化的方案。我曾在KVM下的GPU虚拟化以及流媒体桌面协议有所尝试。

总结：

目前国内教育行业虚拟化前景广阔，但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心，厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了，这点我相信会是一个很好的开端。

银行

目前国内教育行业虚拟化前景广阔，但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心，厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了，这点我相信会是一个很好的开端。

场景分析：

私有云在银行中目前在研发中心、服务集群、营业网点中都有应用，由于笔者经验有限，在此我们进行的讨论仅限于柜台虚拟桌面。

银行中现阶段核心业务由于历史原因，仍有相当部分的小型机在运行，x86服务器份额也在逐渐提高，并且慢慢取代小机成为核心业务承载。由于银行IT的特殊要求，他们使用虚拟化的步伐比较缓慢，一般在其研发机构或者网点柜台中使用较多。

用户桌面：

柜台桌面功能较为单一，从早期的DOS系统到现在的Win7桌面，柜员也只限于在上面查询、办理业务。所需软件除Office以为，也有一部分本行开发的软件与指定的杀毒软件。对于外设，常见的有高清摄像头、POS设备、读卡设备等。

系统维护：

柜台桌面一般会要求还原模式的桌面，大型网点部署在网点内部，小型网点部署在机房，由IT部门定期维护，系统一旦部署完成之后维护量较少。他们对于虚拟化的要求既是性能和功能只要满足，界面上复杂一些也能接受。

痛点----->外设接入：

那么问题来了，银行柜员桌面的外接设备繁多，除USB口以外也有串口、并口等设备。这些对于物理机来说都很轻松，但是到了虚拟机以后，就会出现这样那样的问题。

读者于此可能会问，外接设备多对于技术上来说只是个协议转发的问题，有什么痛处呢？笔者总结有如下原因：

设备接入到虚拟机以后，数据传输所需的额外带宽可能会对柜员机的其他业务产生影响，降低实时性，但是如果将可压缩数据进行无损压缩，对服务器和客户端又带来一定压力，需要较高性能的服务器与客户的才能保证实时性，势必又会导致虚拟化成本的上升。

由于设备与接口繁多，一般的虚拟化厂商需要投入很大一部分物力与财力，甚至要开发专门的硬件设备来进行设备的重定向操作。很多设备尽管接口相同，但经过重定向以后仍然会出现不可识别的情况，需要厂商到现场进行测试甚至开发。

正因为以上两点综合技术因素，现在众多虚拟化厂商谈到银行外设时仍谈虎色变。
痛点----->高实时性：

影响柜台桌面实时性要求的主要因素有两个，一个是客户端到桌面的连接，另一个是桌面到业务系统的连接。

一般由于虚拟桌面是由IT部门直接部署在离业务系统逻辑位置较近的地方，其网络质量较高，可以保证桌面到业务系统的延迟满足要求。但是客户端到桌面的网络是使用银行专有网络，网点到机房的带宽有限，并发高了以后网络拥堵所造成的延迟甚至丢包都会出现。

总结：

银行业相较于其他行业，其IT技术既先进又保守，而虚拟化产品除VMWare老牌厂商或者有行业背景的厂商外，他们的IT部门或多或少的有一定排斥心理。虽然银行客户交涉难度较大，但是如果成功以后就会树立很良好的产品及企业形象，所以，请努力。

一般类提示

eth1: Too much work at interrupt, IntrStatus=0x0001

这条提示的含意为. 某网卡的中断请求过多. 如果只是偶尔出现一次可忽略. 但这条提示如果经常出现或是集中出现,那涉及到的可能性就比较多有可能需要进行处理了. 可能性比较多,如网卡性能;服务器性能;网络攻击..等等.

IPVS: incoming ICMP: failed checksum from 61.172.0.X!

服务器收到了一个校验和错误的ICMP数据包. 这类的数据包有可能是非法产生的垃圾数据.但从目前来看服务器收到这样的数据非常多.一般都忽略.
一般代理服务器在工作时会每秒钟转发几千个数据包.收到几个错误数据包不会影响正常的工作.
这是问我最多的一类提示了.

NET: N messages suppressed.  or  __ratelimit: N messages suppressed。

服务器忽略了 N 个数据包.和上一条提示类似.服务器收到的数据包被认为是无用的垃圾数据数据. 这类数据多是由攻击类的程序产生的.
这条提示如果 N 比较小的时候可以忽略.但如果经常或是长时间出现3位数据以上的这类提示.就很有可能是服务器受到了垃圾数据类的带宽攻击了.


UDP: bad checksum. From 221.200.X.X:50279 to 218.62.X.X:1155 ulen 24 
UDP: short packet: 218.2.X.X:3072 3640/217 to 222.168.X.X:57596
218.26.131.X sent an invalid ICMP type 3, code 13 error to a broadcast: 0.1.0.4 on eth0

服务器收到了一个错误的数据包.分别为 UDP校验和错误; 过短的UDP数据包; 一个错误的ICMP类型数据. 这类信息一般情况下也是非法产生的.
但一般问题不大可直接忽略.


kernel: conntrack_ftp: partial 227 2205426703+13
FTP_NAT: partial packet 2635716056/20 in 2635716048/2635716075

服务器在维持一条FTP协议的连接时出错. 这样的提示一般都可以直接忽略.


eth1: Promiscuous mode enabled. 
device eth1 entered promiscuous mode
device eth1 left promiscuous mode

这几行提示指. 某块网卡进入(离开)了混杂模式. 一般来说混杂模式是当需要对通信进行抓包时才用到的. 当使用维护或故障分析时会使用到(比如consoletools中的countflow命令). 正常产生的这类提示可以忽略.
如果在前台和远端都没有进行维护时出现这个提示倒是应该引起注意,但这种可能性不大.


基本无关

keyboard: unknown scancode e0 5e

键盘上接收到未定义的键值. 如果经常出现.有可能是键盘有问题. linux对于比较特殊的键或是组合键,有时也会出这样的提示.
要看一下服务器的键盘是不是被压住了. 其它情况一般忽略.


 uses obsolete (PF_INET,SOCK_PACKET)

系统内核调用了一部分功能模块,在第一次调入时会出现. 一般情况与使用调试工具有关. 可直接忽略.

 

报警程序的提示 

0001 WMPCheckV001 2005-04-13_10:10:01 Found .(ARP Spoofing sniffer)! IP:183 MAC:5
0002 WMPCheckV001 2005-04-07_01:53:32 Found .(MAC_incomplete)! IP:173 mac_incomplete:186
0003 WMPCheckV001 2005-04-17_16:25:11 Found .(HIGH_synsent)! totl:4271 SynSent:3490
0004 WMPCheckV001 20......

这是由报警程序所引起的提示. 详细的信息需要用报警程序的客户端进行实时接收.

网络通信故障

Neighbour table overflow.

出现这个提示.一般都是因为局域网内有部分计算机被病毒感染. 情况严重时会影响通信. 必须处理内部网通信不正常的计算机.


eth1: Transmit error, Tx status register 82.
Probably a duplex mismatch. See Documentation/networking/vortex.txt
Flags; bus-master 1, dirty 9994190(14) current 9994190(14)
Transmit list 00000000 vs. f7171580.
0: @f7171200 length 800001e6 status 000101e6
1: @f7171240 length 8000008c status 0001008c
.... 

这个提示是3com网卡特有的. 感觉如果出现量不大的话也不会影响很严重. 目前看维一的解决办法是更换服务器上的网卡. 实在感觉3com的网卡有些问题...


网络通信严重问题! 

NETDEV WATCHDOG: eth1: transmit timed out
eth1: link down
eth1: link up, 10Mbps, half-duplex, lpa 0x0000
eth2: link up, 100Mbps, full-duplex, lpa 0x41E1
setting full-duplex based on MII #24 link partner capability of 45e1

这些提示是网络通信中出现严重问题时才会出现. 故障基本和网络断线有关系. 这几条提示分别代表的含意是 某块网卡传送数据超时; 网卡连接down; 网卡连接up,连接速率为10/100Mbps,全/半双功.
这里写到的最后三行的提示比较类似. 出现这类提示时必须注意网络连接状况进行处理!!!


NIC Link is Up 100 Mbps Full Duplex

情况和 kernel: eth1: link up,...相同.指某块网卡适应的连接速率. 一般认为没有说明哪个网卡down,只是连续出现网卡适应速率也是通信有问题.
如果是网线正常的断接可以忽略这类的信息.


eth0: Transmit timed out, status 0000, PHY status 786d, resetting...
eth0: Reset not complete yet. Trying harder.

第一条提示 网卡关送数据失败. 复位网卡. 第二条提示 网卡复位不成功.... 这些提示都属于严重的通信问题.


服务器系统严重故障

CPU0: Temperature above threshold
CPU0: Running in modulated clock mode

服务器CPU工作温度过高. 必须排除硬件故障.


I/O error, dev hda, sector N
I/O error, dev sda, sector N
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=811562, sector=811560

服务器系统磁盘存储卡操作失败. 这样的问题一般不会使服务器直接停止工作, 但会引起很多严重问题.

收到告警邮件，监控一台java web服务器的端口链接超时，登录到服务器上查看/var/log/message log如下：

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:01 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:02 java_web1 kernel: TCP: time wait bucket table overflow

Feb 27 22:32:02 java_web1 kernel: TCP: time wait bucket table overflow

 服务器的TCP连接数，超出了内核定义最大数。
 
查看设置的参数：

[root@java_web1 ~]# cat  /proc/sys/net/ipv4/tcp_max_tw_buckets

5000

才5千，用ss -tan state time-wait | wc -l命令查看，已经有4500多的time-wait链接。
 
解决方法：
修改内核参数 /proc/sys/net/ipv4/tcp_max_tw_buckets

# echo 30000 > /proc/sys/net/ipv4/tcp_max_tw_buckets

写入/etc/sysctl.conf使之永久生效

echo 'net.ipv4.tcp_max_tw_buckets = 30000' >> /etc/sysctl.conf && sysctl -p

转载请注明来自开源技术社区 : http://openskill.cn/article/279

1. 查看系统内核版本​

[root@funsion geekxa]# cat /etc/issue

CentOS release 6.5 (Final)

Kernel \r on an \m

显示了系统名称(CentOS)和内核版本（release 6.5）
The file /etc/issue is a text file which contains a message or system identification to be printed before the login prompt. 
 
2. 查看系统信息

flyhup@ubuntu:~$ uname -a

Linux ubuntu 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015 i686 i686 i686 GNU/Linux

uname -a ：显示系统名、节点名称、操作系统的发行版号、操作系统版本、运行系统的机器 ID 号
 
3. 查看磁盘空间占用情况

$df -hl

Filesystem            Size  Used Avail Use% Mounted on

/dev/xvda1            100G  5.0G   90G   6% /

tmpfs                 1.9G  104K  1.9G   1% /dev/shm

参数：

[]-h:方便阅读[/][]-a：全部文件系统列表[/]

4. 查看内存一、free命令

root@xen_202_12 /]# free -m             total       used       free     shared    buffers     cachedMem:          3072       2459        612          0        207       1803-/+ buffers/cache:        447       2624Swap:         1913          0       1913

第2行:

[]otal 内存总数: 3072【注意单位是M，可以用参数-hm更醒目】[/][]used 已经使用的内存数: 2459[/][]free 空闲的内存数: 612[/][]shared 当前已经废弃不用，总是0[/][]buffers: Buffer Cache内存数: 207[/][]cached: Page Cache内存数: 2803[/][]关系：total = used + free[/]

 第3行:

[]-/+ buffers/cache的意思:[/][]-buffers/cache 的内存数: 447 (等于第1行的 used - buffers - cached)[/][]+buffers/cache 的内存数: 2624 (等于第1行的 free + buffers + cached)[/]

注:此处的内存数在用上面式子计算后，在大小上有一点点出入(还不知道是什么原因)。可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。 5. 查看cpu内核数

# 总核数 = 物理CPU个数 X 每颗物理CPU的核数 # 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数# 查看物理CPU个数cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l# 查看每个物理CPU中core的个数(即核数)cat /proc/cpuinfo| grep "cpu cores"| uniq# 查看逻辑CPU的个数cat /proc/cpuinfo| grep "processor"| wc -l

 6. 查看系统负载

dimite@ubuntu:~$ uptime15:41:09 up 42 min,  2 users,  load average: 0.08, 0.03, 0.05

[]当前时间 15:41:09[/][]系统已运行的时间 42min[/][]当前在线用户 2 user[/][]平均负载：0.54, 0.40, 0.20，最近1分钟、5分钟、15分钟系统的负载[/]

何为系统负载呢？系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数目。如果一个进程满足以下条件则其就会位于运行队列中：

[]它没有在等待I/O操作的结果[/][]它没有主动进入等待状态(也就是没有调用'wait')[/][]没有被停止(例如：等待终止)[/]

一般来说，每个CPU内核当前活动进程数不大于3，则系统运行表现良好！当然这里说的是每个cpu内核，也就是如果主机是四核cpu的话，那么只要uptime最后输出的一串字符数值小于12即表示系统负载不是很严重.当然如果达到20，那就表示当前系统负载非常严重，估计打开执行web脚本非常缓慢. 7. 查看进程

ps -ef  or ps aux

杀死所有含worker的进程

ps -ef | grep worker | awk '{print $2}' | xargs sudo kill -9orps -aux | grep worker | awk '{print $2}' | xargs sudo kill -9

8. 查看端口占用

netstat -anpornetstat -nltup

参数：

[]-a (all)显示所有选项，默认不显示LISTEN相关[/][]-t (tcp)仅显示tcp相关选项[/][]-u (udp)仅显示udp相关选项[/][]-n 拒绝显示别名，能显示数字的全部转化成数字。[/][]-l 仅列出有在 Listen (监听) 的服務状态[/][]-p 显示建立相关链接的程序名[/][]-r 显示路由信息，路由表[/][]-e 显示扩展信息，例如uid等[/][]-s 按各个协议进行统计[/][]-c 每隔一个固定时间，执行该netstat命令。[/][]提示：LISTEN和LISTENING的状态只有用-a或者-l才能看到[/]

继上一篇文章TIME_WAIT和CLOSE_WAIT解疑(上), 继续答疑！
先回答几个问题​：
Q：请问我们所说连接池可以复用连接，是不是意味着，需要等到上个连接time wait结束后才能再次使用?

A：所谓连接池复用，复用的一定是活跃的连接，所谓活跃，第一表明连接池里的连接都是ESTABLISHED的，第二，连接池做为上层应用，会有定时的心跳去保持连接的活跃性。既然连接都是活跃的，那就不存在有TIME_WAIT的概念了，在上篇里也有提到，TIME_WAIT是在主动关闭连接的一方，在关闭连接后才进入的状态。既然已经关闭了，那么这条连接肯定已经不在连接池里面了，即被连接池释放了。

Q：想请问下，作为负载均衡的机器随机端口使用完的情况下大量time_wait，不调整你文字里说的那三个参数，有其他的更好的方案吗？​

第一，随机端口使用完，你可以通过调整/etc/sysctl.conf下的net.ipv4.ip_local_port_range配置，至少修改成 net.ipv4.ip_local_port_range=1024 65535，保证你的负载均衡服务器至少可以使用6万个随机端口，也即可以有6万的反向代理到后端的连接，可以支持每秒1000的并发（想一想，因为TIME_WAIT状态会持续1分钟后消失，所以一分钟最多有6万，每秒1000）；如果这么多端口都使用完了，也证明你应该加服务器了，或者，你的负载均衡服务器需要配置多个IP地址，或者，你的后端服务器需要监听更多的端口和配置更多的IP（想一下socket的五元组）

第二，大量的TIME_WAIT，多大量？如果是几千个，其实不用担心，因为这个内存和CPU的消耗有一些，但是是可以忽略的。

第三，如果真的量很大，上万上万的那种，可以考虑，让后端的服务器主动关闭连接，如果后端服务器没有外网的连接只有负载均衡服务器的连接（主要是没有NAT网络的连接），可以在后端服务器上配置tw_recycle，然后同时，在负载均衡服务器上，配置tw_reuse。参见本文后面的解释。

Q：如果想深入的学习一下网络方面的知识，有什么推荐的？

学习网络比学一门编程语言“难”很多。所谓难，其实，是因为需要花很多的时间投入。我自己不算精通，只能说入门和理解。基本书可以推荐：《TCP/IP 协议详解》，必读；《TCP/IP高效编程：改善网络程序的44个技巧》，必读；《Unix环境高级编程》，必读；《Unix网络编程：卷一》，我只读过卷一；另外，还需要熟悉一下网络工具，tcpdump以及wireshark，我的notes里有一个一站式学习Wireshark：https://github.com/dafang/notebook/issues/114，也值得一读。有了这些积累，可能就是一些实践以及碎片化的学习和积累了。

TIME_WAIT很多，可怕吗？

如果你通过 ss -tan state time-wait | wc -l 发现，系统中有很多TIME_WAIT，很多人都会紧张。多少算多呢？几百几千？如果是这个量级，其实真的没必要紧张。第一，这个量级，因为TIME_WAIT所占用的内存很少很少；因为记录和寻找可用的local port所消耗的CPU也基本可以忽略。

会占用内存吗？当然！任何你可以看到的数据，内核里都需要有相关的数据结构来保存这个数据啊。一条Socket处于TIME_WAIT状态，它也是一条“存在”的socket，内核里也需要有保持它的数据：

[]内核里有保存所有连接的一个hash table，这个hash table里面既包含TIME_WAIT状态的连接，也包含其他状态的连接。主要用于有新的数据到来的时候，从这个hash table里快速找到这条连接。不同的内核对这个hash table的大小设置不同，你可以通过dmesg命令去找到你的内核设置的大小：[/]

[]还有一个hash table用来保存所有的bound ports，主要用于可以快速的找到一个可用的端口或者随机端口：[/]

由于内核需要保存这些数据，必然，会占用一定的内存。 会消耗CPU吗？当然！每次找到一个随机端口，还是需要遍历一遍bound ports的吧，这必然需要一些CPU时间。

TIME_WAIT很多，既占内存又消耗CPU，这也是为什么很多人，看到TIME_WAIT很多，就蠢蠢欲动的想去干掉他们。其实，如果你再进一步去研究，1万条TIME_WAIT的连接，也就多消耗1M左右的内存，对现代的很多服务器，已经不算什么了。至于CPU，能减少它当然更好，但是不至于因为1万多个hash item就担忧。

如果，你真的想去调优，还是需要搞清楚别人的调优建议，以及调优参数背后的意义！ TIME_WAIT调优，你必须理解的几个调优参数在具体的图例之前，我们还是先解析一下相关的几个参数存在的意义。net.ipv4.tcp_timestamps

RFC 1323 在 TCP Reliability一节里，引入了timestamp的TCP option，两个4字节的时间戳字段，其中第一个4字节字段用来保存发送该数据包的时间，第二个4字节字段用来保存最近一次接收对方发送到数据的时间。有了这两个时间字段，也就有了后续优化的余地。tcp_tw_reuse 和 tcp_tw_recycle就依赖这些时间字段。

net.ipv4.tcp_tw_reuse

字面意思，reuse TIME_WAIT状态的连接。时刻记住一条socket连接，就是那个五元组，出现TIME_WAIT状态的连接，一定出现在主动关闭连接的一方。所以，当主动关闭连接的一方，再次向对方发起连接请求的时候（例如，客户端关闭连接，客户端再次连接服务端，此时可以复用了；负载均衡服务器，主动关闭后端的连接，当有新的HTTP请求，负载均衡服务器再次连接后端服务器，此时也可以复用），可以复用TIME_WAIT状态的连接。通过字面解释，以及例子说明，你看到了，tcp_tw_reuse应用的场景：某一方，需要不断的通过“短连接”连接其他服务器，总是自己先关闭连接(TIME_WAIT在自己这方)，关闭后又不断的重新连接对方。那么，当连接被复用了之后，延迟或者重发的数据包到达，新的连接怎么判断，到达的数据是属于复用后的连接，还是复用前的连接呢？那就需要依赖前面提到的两个时间字段了。复用连接后，这条连接的时间被更新为当前的时间，当延迟的数据达到，延迟数据的时间是小于新连接的时间，所以，内核可以通过时间判断出，延迟的数据可以安全的丢弃掉了。这个配置，依赖于连接双方，同时对timestamps的支持。同时，这个配置，仅仅影响outbound连接，即做为客户端的角色，连接服务端[connect(dest_ip, dest_port)]时复用TIME_WAIT的socket。

net.ipv4.tcp_tw_recycle

字面意思，销毁掉 TIME_WAIT。当开启了这个配置后，内核会快速的回收处于TIME_WAIT状态的socket连接。多快？不再是2MSL，而是一个RTO（retransmission timeout，数据包重传的timeout时间）的时间，这个时间根据RTT动态计算出来，但是远小于2MSL。有了这个配置，还是需要保障 丢失重传或者延迟的数据包，不会被新的连接(注意，这里不再是复用了，而是之前处于TIME_WAIT状态的连接已经被destroy掉了，新的连接，刚好是和某一个被destroy掉的连接使用了相同的五元组而已)所错误的接收。在启用该配置，当一个socket连接进入TIME_WAIT状态后，内核里会记录包括该socket连接对应的五元组中的对方IP等在内的一些统计数据，当然也包括从该对方IP所接收到的最近的一次数据包时间。当有新的数据包到达，只要时间晚于内核记录的这个时间，数据包都会被统统的丢掉。这个配置，依赖于连接双方对timestamps的支持。同时，这个配置，主要影响到了inbound的连接（对outbound的连接也有影响，但是不是复用），即做为服务端角色，客户端连进来，服务端主动关闭了连接，TIME_WAIT状态的socket处于服务端，服务端快速的回收该状态的连接。由此，如果客户端处于NAT的网络(多个客户端，同一个IP出口的网络环境)，如果配置了tw_recycle，就可能在一个RTO的时间内，只能有一个客户端和自己连接成功(不同的客户端发包的时间不一致，造成服务端直接把数据包丢弃掉)。

我尽量尝试用文字解释清楚，但是，来点案例和图示，应该有助于我们彻底理解。我们来看这样一个网络情况： [list=1][]客户端IP地址为：180.172.35.150，我们可以认为是浏览器[/][]负载均衡有两个IP，外网IP地址为 115.29.253.156，内网地址为10.162.74.10；外网地址监听80端口[/][]负载均衡背后有两台Web服务器，一台IP地址为 10.162.74.43，监听80端口；另一台为 10.162.74.44，监听 80 端口[/][]Web服务器会连接数据服务器，IP地址为 10.162.74.45，监听 3306 端口[/]这种简单的架构下，我们来看看，在不同的情况下，我们今天谈论的tw_reuse/tw_recycle对网络连接的影响。 先做个假定：[list=1][]客户端通过HTTP/1.1连接负载均衡，也就是说，HTTP协议投Connection为keep-alive，所以我们假定，客户端 对 负载均衡服务器 的socket连接，客户端会断开连接，所以，TIME_WAIT出现在客户端[/][]Web服务器和MySQL服务器的连接，我们假定，Web服务器上的程序在连接结束的时候，调用close操作关闭socket资源连接，所以，TIME_WAIT出现在 Web 服务器端。[/] 那么，在这种假定下：[list=1][]Web服务器上，肯定可以配置开启的配置：tcp_tw_reuse；如果Web服务器有很多连向DB服务器的连接，可以保证socket连接的复用。[/][]那么，负载均衡服务器和Web服务器，谁先关闭连接，则决定了我们怎么配置tcp_tw_reuse/tcp_tw_recycle了[/] 方案一：负载均衡服务器 首先关闭连接 在这种情况下，因为负载均衡服务器对Web服务器的连接，TIME_WAIT大都出现在负载均衡服务器上，所以，在负载均衡服务器上的配置：

[]net.ipv4.tcp_tw_reuse = 1 //尽量复用连接[/][]net.ipv4.tcp_tw_recycle = 0 //不能保证客户端不在NAT的网络啊[/]

 在Web服务器上的配置为：

[]net.ipv4.tcp_tw_reuse = 1 //这个配置主要影响的是Web服务器到DB服务器的连接复用[/][]net.ipv4.tcp_tw_recycle： 设置成1和0都没有任何意义。想一想，在负载均衡和它的连接中，它是服务端，但是TIME_WAIT出现在负载均衡服务器上；它和DB的连接，它是客户端，recycle对它并没有什么影响，关键是reuse[/]

 方案二：Web服务器首先关闭来自负载均衡服务器的连接在这种情况下，Web服务器变成TIME_WAIT的重灾区。负载均衡对Web服务器的连接，由Web服务器首先关闭连接，TIME_WAIT出现在Web服务器上；Web服务器对DB服务器的连接，由Web服务器关闭连接，TIME_WAIT也出现在它身上，此时，负载均衡服务器上的配置：

[]net.ipv4.tcp_tw_reuse：0 或者 1 都行，都没有实际意义[/][]net.ipv4.tcp_tw_recycle=0 //一定是关闭recycle[/]

 在Web服务器上的配置：

[]net.ipv4.tcp_tw_reuse = 1 //这个配置主要影响的是Web服务器到DB服务器的连接复用[/][]net.ipv4.tcp_tw_recycle=1 //由于在负载均衡和Web服务器之间并没有NAT的网络，可以考虑开启recycle，加速由于负载均衡和Web服务器之间的连接造成的大量TIME_WAIT[/]

 

作者：大房说
分享阅读地址：http://dwz.cn/2NgmFY

软件架构介绍

架构定义：

软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。

软件架构的目标：

[]可延伸性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展；[/][]可维护性（Maintainable）。软件系统的维护包括两方面：1、排除现有的错误；2、将新的软件需求反映到现有系统中去，一个易于维护的系统可以有效地降低技术支持的花费。[/][]客户体验（Customer Experience）。软件系统必须易于使用。[/][]市场时机（Time to Market）。软件用户[/]

 软件逻辑架构：

逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等

软件系统的逻辑架构图：  软件物理架构：

物理架构：软件元件是怎样放到硬件上的？

软件系统的物理架构图

物联网架构的演变

单机(One Box)简单web应用：

[]访问量小[/][]Apache/PHP/MySQL 在同一主机上[/][]瓶颈[/]

                 1、通常先出现在数据库，然后才是Apache/php                 2、硬盘 I/O (Innodb) 或MyISAM锁等待  双机(Two Box)

[]访问量逐渐增大[/][]Apache/PHP在Server A；MySQL在Server B[/][]瓶颈[/]

                 1、硬盘 I/O (Innodb) 或MyISAM锁等待                 2、网络I/O  多机 (Many Boxes with Replication)

[]访问量继续增大[/][]MySQL主从复制及读写分离 (master 负责IN/UP/DEL, slave负责 SELECT)[/][]SELECT, IN/UP/DEL可以在应用程序内指定访问不同服务器 （如使用不同的handle或Db Adapter）[/][]WEB Server可能需要使用负载均衡[/][]NoSQL/Cache/CDN[/]

 系统分层：

Cache Tier

Memcached、Redis等广泛使用。

架构新问题Mysql：[list=1][]Slave Lag 每台Slave数据完全一样。有的忙，有的闲[/][]数据量越来越大，单表过大，查询效率太低；[/]综合1.2 通常采用

[]memcached数据缓存 [/][]MySQL水平扩展（库表拆分）[/]

Web Server 负载过高 

[]提高PHP代码执行效率 Opcode Cache[/][]静态文件缓存  Squid/Varnish / CDN[/][]负载均衡[/]

 新架构目标：

[]高可用[/][]高性能 [/][]可扩展 [/][]监控[/][]成本控制[/]

分布式系统架构

分布式系统概念

What is a Distributed System?“一个分布式系统是若干个独立的计算机的集合，但是对该系统的用户来说，系统就像一台计算机一样。”

两方面的含义：[list=1][]硬件方面：各个计算机都是自治的 [/][]软件方面：用户将整个系统看作是一台计算机 [/]  分布式系统定义：

一个分布式系统组织成中间件形式，中间件层分布在多台机器上。

分布式系统优点： 分布式操作系统特点：  网络操作系统（NOS）网络操作系统的一般结构： 分布式系统中设计的关键问题：透明性（对用户、程序） 灵活性 单内核基本上是目前的集中式操作系统，增加了网络功能和远程服务集合。 微内核的四种基本服务：        （1）进程间通信机制        （2）少量内存管理功能        （3）必要的低层进程管理和调度        （4）低层输入／输出服务可靠性

性能

可伸缩性（scalability）避免：

[]集中式硬件[/][]集中式算法[/][]集中式的数据结构[/]

 

可扩展性

[]没有一台机器上存放着关于系统状态的全部信息[/][]机器只是基于本地信息做出决定[/][]一个机器出故障不会破坏算法[/][]不一定存在全局时钟。[/]

可扩展性示例：

总结

没有固定的架构，架构都是随着时间和业务的迁徙和变动而发生改变和重构的。所以架构不是一成不变的，也不是淘宝的架构就是万能的，适应你们业务的架构演变的架构就是最优架构。万变不离其宗，但是其底层技术实现和方法是可以借鉴采用大公司场景做法。

1、从http://www.macapp.so/coderunner/​  下载软件安装包，访问截图如下


2、断网安装①和② (②是注册器)

双击可以复制。
确定以后 会出来英文。。。。。。。。。valid（说key是有效的)。说明成功了 然后关闭就行了
 
3、最重要的一步编辑hosts文件！（屏蔽coderunnerapp.com的联网验证！ ）
编辑/etc/hosts文件添加一个coderunnerapp.com的配置，如下所示：

# sudo vim /etc/hosts

 
4、成功！不会再出来 输入验证码的地方了

破解结束，可以愉快的使用了！

网络拓扑结构类型

类型图如下：

1、星型拓扑结构

特点：

通信协议简单，站点故障容易检测和隔离.连线费用大，中央结点要求高。

2、总线形拓扑结构

特点：

连线总长度小于星型结构，站点容易扩充和删除.总线任务重，易产生瓶颈问题。

3、环形拓扑结构

特点：

传输速率高，传输距离远.一个站点的故障会形起整个网络的崩溃。

4、数型拓扑结构

特点：

通信线路连接简单，网络管理软件也不复杂，维护方便；

资源共享能力差，可靠性低。

网络的基本组成

网络软件：网络软件包括网络操作系统、通信软件和网络协议等 。
 

OSI模式图：

OSI模型介绍：

[]应用层：该层是开放系统的最高层，直接为最终用户服务。主机上的用户都在应用层上。用户只需关心正在交换的信息，不必知道信息传输的技术，因此，应用层的功能只是处理双方交换来往的信息。 [/][]表示层：表示层如同应用程序和网络之间的翻译，在表示层，数据将按照网络能理解的方案进行格式转化，这种格式转化的结果也因所使用网络的类型不同而不同。表示层管理数据的解密与加密，如系统口令的处理。 [/][]会话层：会话层的功能包括：建立通信链接，保持会话过程通信链接的畅通，同步两个节点之间的对话，决定通信是否被中断以及通信中断时决定从何处重新发送。 [/][] [/][]传输层：传输层主要负责确保数据可靠、顺序、无错地传输。如果没有传输层，数据将不能被接收方验证或解释，所以，传输层常被认为是OSI模型中最重要的一层。 [/][]网络层：即OSI模型的第三层，其主要功能是将网络地址翻译成对应的物理地址，并决定如何将数据从发送方路由到接收方。[/][]数据链路层：数据链路层是OSI模型的第二层，其控制网络层与物理层之间的通信。它的主要功能是将网络层接收到的数据分割成特定的可被物理层传输的帧。[/][]物理层：物理层负责线路的连接，并把需要传送的信息转变为可以在实际线路上运送的物理信号，如电脉冲。信号电平的高低、插头插座的规格、调制解调器都属于这一层。 [/]

 网络协议：

[]协议是通信双方所共同遵循的规则。协议实际上是一组指挥行为的规则或准则。就像打电话过程必须要服从一个通话的规则，如果不懂这个规则，双方就无法通话。[/][]网络中的两台计算机之间交换信息也有一些规则和约定，这就是网络协议，为保证能够正确传送数据，发送和接收数据的计算机都必须遵守协议，以确保发送和接收的数据有序准确。每个网络至少有一种协议。网络中的计算机将遵循网络设计者所选择的协议进行通信。[/]

网络协议是为网络数据交换而制定的的规则、约定与标准。   下面我们通过实例，介绍对等层通信示例：邮递过程

问题：[list=1][]收信人与发信人之间、邮政局之间，他们是在直接通信吗？[/][]邮政局、运输系统各向谁提供什么样的服务？[/][]邮政局、收发信人各使用谁提供的什么服务？[/]分析前面通信的例子，我们会发现：

[]模型具有三个层次 [/][]相同层次的交流都是独立进行的，不受其他层次影响[/][]上下相邻两个层次之间的联系可以用“提供服务”和“使用服务”来进行说明 [/]

 网络协议的选择

[]网络规模较小，只是为了文件传输和设备共享，这时最好选择占用内存较小和带宽利用率高的协议——NETBEUI协议。[/][]若使用Netware网络操作系统，在局域网中联机游戏，那么IPX/SPX协议是不错的选择。[/][]若要规划一个高效率、可互连性和扩展性强的网络，并与Internet实现连接，那么TCP/IP是理想之选。[/]

  分层体系结构

为了解决不同媒介连接起来的不同设备和网络系统在不同的应用环境下实现互操作的问题，采用分层的方法，将网络互联的庞大而复杂的问题，划分为若干个较小而容易解决的问题。对等层之间执行相同的操作，较低层向上一层提供服务。

 OSI层次模型

为了解决不同的网络之间进行通信的问题，国际标准化组织（ISO）提出了一种网络模型，即开放系统互连参考模型，简称OSI层次模型。

OSI: Open System Interconnection

 TCP/IP协议

[]TCP（Transmission Control Protocol）传输控制协议用于保证被传送信息的完整性。[/][]IP（Internet Protocol）网际互连协议负责将消息从一个地方传送到另一个地方。[/]

TCP/IP资料： http://www.internic.net

[]TCP/IP起源于美国国防部高级研究规划署(DARPA)的一项研究计划——实现若干台主机之间的相互通信。[/][]现在TCP/IP已成为Internet上通信的标准。[/][]TCP/IP模型包括4个概念层次：[/]

                              应用层（application）                              传输层（transport）                              网际层（internet）                              网络接口（network interface）

[]TCP/IP协议叫做传输控制协议/网际协议，是互联网信息交换、规则、规范的集合体。 [/][]虽然从名字上看 TCP/IP包括两个协议：传输控制协议（TCP）和网际协议（IP），实际上它是一组协议，它包括上百个各种功能的协议，如远程登录、文件传输和电子邮件等等，而 TCP协议和IP协议是保证数据完整传输的两个基本的重要协议。通常说TCP/IP是Internet协议族，而不单单是TCP和IP。[/][]TCP/IP是通用标准，OSI是国际标准。[/]

 TCP/IP 模型与 OSI 参考模型对比

[]TCP是面向连接的协议，它负责保证数据按次序、安全、无重复地传递。提供高可靠性服务，用于一次传输要交换大量报文的情形。[/][]UDP提供了是高效率服务。用于一次传输交换少量报文，如即时通信中的QQ、ICQ，传输的可靠性由应用程序提供保障。[/][]端口是TCP和UDP与应用程序打交道的访问点。如80端口是万维网常用的，21与20是FTP常用的，23是Telnet服务的端口。[/][]IP协议是一个不可靠的无连接协议，它提供将一个数据报从一台计算机或设备传送于另一台计算机或设备的方法以及网络寻址的方法。[/]

 网络地址

IP地址是IP协议提供的一种地址格式，它为Internet上的每一个网络和每一台主机分配一个网络地址，以此来屏蔽物理地址的差异。是运行TCP/IP协议的唯一标识。

 IP地址类型

 DNS域名系统DNS采用分层次结构，入网的每台主机都可以有一个类似下面的域名： 从左到右，域的范围变大。具有实际含义，比IP地址好记。Internet上几乎在每一子域都设有域名服务器，服务器中包含有该子域的全体域名和地址信息。Internet每台主机上都有地址转换请求程序，负责域名与IP地址转换。 VLAN概诉  VLAN特点

[]VLAN之间互相隔离，就好象用户连接到不同的交换机一样。[/]

[]VLAN之间互相隔离，就好象用户连接到不同的交换机一样；[/][]VLAN可以跨越多个交换机。[/]

[]VLAN之间互相隔离，就好象用户连接到不同的交换机一样；[/][]VLAN可以跨越多个交换机；[/][]TRUNK(干道)传送多个VLAN的数据，它们使用“封装”标记不同VLAN的数据[/]

  VLAN指定：动态与静态

 VPN (Virtual Private Network)

 VPN类型PPTP (Point-to-point Tunneling Protocol)         用户到NAS之间的连接保密         口令机制CHAPL2TP (Layer2 Tunneling Protocol)         第二层安全，IPSEC (Internet Protocol Security)        最完善的安全机智 VPN与专用网相比的优势

[]租线路便宜[/][]无须专用接入设备[/][]移动时节约长途电话开销[/][]大规模造成的复杂问题不存在[/][]管理更容易[/][]扩展方便[/]

 VPN与专用网相比的优势的缺点

[]设备成本，如果需要高性能的话[/][]技术门槛，维护和管理开销[/][]法律问题[/][]性能问题，服务质量[/]

 
 
 
CDN理解
         CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。


CDN工作原理（以DNS重定向为例）


CDN关键技术

 
CDN热门应用-视频分发

 
CDN整体网络架构

总结

网络管理知识点就给大家介绍这么多了，希望大家有收获。更多知识需要大家去深入了解、发掘。新时代、互联网创客时代/技术变革的时代，我们IT技术圈也有很多新芽的技术等待你去探索和发掘！