云端框架v1.0Alpha版​

框架引擎

Python 2.7.9 、Cherrypy 3.6.0 、Mako 1.0.1 

本次架构纯属个人兴趣所致，如今开发各类机器人也并非难事，本框架基于最简单的Wechat Http协议所开发 网上关于Wechat的 Web协议分析的资料也不少。这里不再赘述。这套协议分析就很不错web 微信与基于node的微信机器人实现 实现的原理都一样，只过是实现的语言不一样而已，笔者用Node做过基于PCQQ协议的消息互通,简单的写了一个简单的Demo，个人对人工智能比较感兴趣啦~ 由于个人能力有限，工作也比较繁忙，所以就将这个云端框架贡献出来~ 希望有志同道合的同仁一起来维护这个框架。在实际测试中感觉Cherrypy这个框架效率还是蛮低的~后来想用Tornado非阻塞的Python web框架 个人精力有限~~

协议分析

[]WEB协议也就是网页版微信 web 协议有web的好处~嘎嘎我就不说了避免XX00[/][]Android/ios协议 市面上很少见。[/]

PC协议 ...........

[]如何使用 搭建好Python环境安装好对应模块 run CherryWeChatSwever.py 代码写的比较渣渣~啦~ 对于新手熟悉CherryPy框架也是不错想选择~[/]

效果展示

ChangeLog 

开源协议

GPL

项目地址：https://github.com/lu4kyd0y/WeChat-Cloud-Robot 收起阅读 »

根据如上思维导图，我们来展开对Zookeeper的基本的一些概念解释。

一、集群角色

Leader

Leader服务器是整个Zookeeper集群工作机制中的核心 

Follower

Follower服务器是Zookeeper集群状态的跟随者

Observer

Observer服务器充当一个观察者的角色

Leader，Follower 设计模式；Observer 观察者设计模式

二、会话

会话是指客户端和ZooKeeper服务器的连接，ZooKeeper中的会话叫Session，客户端靠与服务器建立一个TCP的长连接；

来维持一个Session,客户端在启动的时候首先会与服务器建立一个TCP连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能向ZK服务器发送请求并获得响应。

三、数据节点

Zookeeper中的节点有两类：

[]集群中的一台机器称为一个节点[/][]数据模型中的数据单元Znode，分为持久节点和临时节点[/]

 

Zookeeper的数据模型是一棵树,树的节点就是Znode，Znode中可以保存信息。

如下图所示：

ZK大致数据结构跟上图是一致的，如上图所示这个图就像一棵树，这个树有个根节点，然后其下有些子节点，然后每个子节点其下又可以有子节点，大多数的开发就是跟zk的这些数据节点打交道，来读写这些数据节点，来完成任务。

四、版本

ZK中的版本，是用来记录节点数据或者是节点的子节点列表或者是权限信息的修改次数，注意是这里是修改次数。如果一个节点的version是1，那就代表说这个节点从创建以来被修改了一次，那么这个版本怎么用呢，典型的我们可以利用版本来实现分布式的锁服务。我们知道在数据库中，一般有两种锁，一种是悲观锁一种是乐观锁。

悲观锁

悲观锁又叫悲观并发锁，是数据库中一种非常严格的锁策略，具有强烈的排他性，能够避免不同事务对同一数据并发更新造成的数据不一致性，在上一个事务没有完成之前，下一个事务不能访问相同的资源，适合数据更新竞争非常激烈的场景；

乐观锁

相比悲观锁，乐观锁使用的场景会更多，悲观锁认为事务访问相同数据的时候一定会出现相互的干扰，所以简单粗暴的使用排他访问的方式，而乐观锁认为不同事务访问相同资源是很少出现相互干扰的情况，因此在事务处理期间不需要进行并发控制，当然乐观锁也是锁，它还是会有并发的控制！对于数据库我们通常的做法是在每个表中增加一个version版本字段，事务修改数据之前先读出数据，当然版号也顺势读取出来，然后把这个读取出来的版本号加入到更新语句的条件中，比如，读取出来的版本号是1,我们修改数据的语句可以这样写，update 某某表 set 字段一=某某值 where id=1 and version=1，那如果更新失败了说明以后其他事务已经修改过数据了，那系统需要抛出异常给客户端，让客户端自行处理，客户端可以选择重试。

锁，ZK中版本有类式的作用。

ZK的版本类型有三种：version cversion aversion

五、Watcher

Watcher我们可以理解为他是一个事件监听器

ZooKeeper允许用户在指定节点上注册一些Watcher，当数据节点发生变化的时候，ZooKeeper服务器会把这个变化的通知发送给感兴趣的客户端。

两个客户端都在zookeeper集群中注册了watcher（事件监听器），那么当zk中的节点数据发生变化的时候，zk会把这一变化的通知发送给客户端，当客户端收到这个变化通知的时候，它可以再回到zk中，去取得这个数据的详细信息。

六、ACL权限控制

 
ACL是Access Control Lists 的简写， ZooKeeper采用ACL策略来进行权限控制，有以下权限：

[]CREATE: 创建子节点的权限[/][]READ: 获取节点数据和子节点列表的权限[/][]WRITE: 更新节点数据的权限[/][]DELETE: 删除子节点的权限[/][]ADMIN: 设置节点ACL的权限[/]

上面的权限有点类似我们信息系统的权限管理，我们在开发系统的时候一般也会对数据做这些权限管理，一个zk集群可能会服务很多的业务，尤其是一些大公司，zk集群的节点中会保存重要的信息，那么这些信息通常只能对一部分的访问者开放，通过acl我们可以对某些节点的访问进行授权，从而来保证数据的安全。

收起阅读 »

顾客就是上帝

传统的行业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部门或多或少的有一定排斥心理。虽然银行客户交涉难度较大，但是如果成功以后就会树立很良好的产品及企业形象，所以，请努力。

收起阅读 »

根据如上思维导图，我来展开对Zookeeper的介绍

一、Zookeeper背景

随着互联网技术的高速发展，企业对计算机系统的计算、存储能力要求越来越高，最简单的证明就是出现了一些诸如：高并发，海量存储这样的词汇。在这样的背景下，单纯依靠少量高性能主机来完成计算任务也就不能满足现有大部分企业的需求了，企业的IT架构逐步从集中式向分布式过度，所谓的分布式是指：把一个计算任务分解成若干个计算单元，并且分配到若干不同的计算机中去执行，然后汇总计算结果的过程。

这好比公司里面的某个团队，接到公司派发的任务，首先团队的主管，要把任务进行拆分，然后安排下去，划分给团队中不同的人去完成，并随时跟进任务的进展。如果团队主管离职了，那我们可能就会在团队中挑选一个对业务比较熟悉的人来接管主管位置。最后各个组员把任务完成，主管进行汇总，并上报给公司。在团队内部需要制定多个工作流程，来保证工作的有序开展。在分布式系统中同样需要设置这么一个协作规范。zookeeper可以很好的帮助我们来实现这个目的。

二、Zookeeper是什么？

ZooKeeper是一个开放源码的分布式协调服务，由知名互联网公司雅虎创建，是基于Google Chubby开源实现。（Google chubby是google公司开源的一个锁服务。）

ZooKeeper是一个高性能的分布式数据一致性解决方案，它将那些复杂的、容易出错的分布式一致性服务封装起来了，构成了一个高效可靠的源语集，并提供一系列简单易用的接口给用户。

ZooKeeper致力于提供一个高性能、高可用、且具有严格的顺序访问控制能力的分布式协调服务。分布式应用可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知，集群管理、Master 选举、分布式锁和分布式队列等功能。

Zookeeper知识点：
1、源代码开放

开源意味着我们可以免费的获取和使用zk，并且可以深入研究zk的源代码，甚至可以根据自己业务特性和要求进行二次开发修改。

2、是分布式协调服务，它解决分布式数据一致性问题
A、顺序一致性

所谓的顺序一致性是指从一个客户端发起一个请求，最终会严格按照发起的顺序应用到zk中。

B、原子性

原子性是指所有事物请求的处理结果在整个集群的所有机器上的应用情况是一致的。

C、单一视图

单一视图是指无任客户端连接到哪个zk的服务器，它看到的服务端数据都是一致的。

D、可靠性

可靠性是指一旦服务端成功的应用了一个事物并完成了对客户端的响应，那么这个事物所引起的服务端状态的变更会一直保留下来，除非有另外一个事物又对它进行了修改。

E、实时性

实时性是指zk保证在一段时间内客户端一定能从服务端读取最新的数据状态。

3、高性能

zk具有很高的吞吐量，一个三台服务器的集群可以达到12w-13w的QPS。

4、我们可以通过调用zk提供的接口解决一些分布式易用中的实际问题。

三、Zookeeper的典型应用场景

Zookeeper包括但不限于如下应用场景
 
3.1、数据发布/订阅

顾名思义就是一方把数据发布出来，另一方通过某种方式可以得到这些数据;

通常数据订阅有两种方式：推送模式和拉取模式

推送模式一般是服务器主动向客户端推送信息， 拉取模式是客户端主动去服务器获取数据（通常是采用定时轮询的方式），ZK采用两种方式相结合;

发布者将数据发布到ZK集群节点上，订阅者通过一定的方法告诉服务器，我对哪个节点的数据感兴趣，那服务器在这些节点的数据发生变化时，就通知客户端，客户端得到通知后可以去服务器获取数据信息。

3.2、负载均衡

实现过程：

1、首先DB在启动的时候先把自己在ZK上注册成一个临时节点，ZK的节点后面我们会讲到有两种，一种是永久节点，一类是临时节点临时节点在服务器出现问题的时候，节点会自动的从ZK上删除，那么这样ZK上的服务器列表就是最新的可用的列表。

2、客户端在需要读写数据库的时候首先它去ZooKeeper得到所有可用的DB的连接信息（一张列表），得到可用的数据列表。

3、客户端随机的算法，随机选择一个与之建立连接，每次会跟不同的数据库连接，就达到简单的复杂均衡。

4、当客户端发现连接不可用的时候可再次从ZK上获取可用的DB连接信息，当然也可以在刚获取的那个列表里移除掉不可用的连接后再随机选择一个DB与之连接。

3.3、命名服务

顾名思义，就是提供名称的服务，例如数据库表格ID，一般用得比较多的有两种ID，一种是自动增长的ID，一种是UUID(9291d71a-0354-4d8e-acd8-64f7393c64ae)，两种ID各自都有缺陷，自动增长的ID局限在单库单表中使用，不能在分布式中使用，UUID可以在分布式中使用但是由于ID没有规律难于理解，我们可以借用ZK来生成一个顺序增长的，可以在集群环境下使用的，命名易于理解的ID。

3.4、分布式协调/通知

心跳检测，在分布式系统中，我们常常需要知道某个机器是否可用，传统的开发中，可以通过Ping某个主机来实现，Ping得通说明对方是可用的，相反是不可用的；

ZK中我们让所有的机其都注册一个临时节点，我们判断一个机器是否可用，我们只需要判断这个节点在ZK中是否存在就可以了，不需要直接去连接需要检查的机器 ，降低系统的复杂度。

四、Zookeeper的优势

[]源代码开放[/][]已经被证实是高性能，易用稳定的工业级产品。[/][]有着广泛的应用：Hadoop,HBase,Storm,Solr。[/]

转载请注明来自开源技术社区 : http://openskill.cn/article/281 收起阅读 »

一般类提示

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、成功！不会再出来 输入验证码的地方了

破解结束，可以愉快的使用了！ 收起阅读 »