行业动态

内网车祸一直是互联网公司尽量避免的事情，也是服务端程序员最关心的问题之一。 但是，如果我们统计一下各种内网事故的原因，我们会发现一个推论：内网事故70%的原因是在运维领域，而只有30%左右的事故原因是由于BUG造成的。程序本身造成的。 这里所说的“运维领域激励”包括配置错误、现网运行错误、网络或其他硬件环境发生变化、硬件故障等。 在盛行“运维”与“开发”分离的时代，虽然这是运维的错，但这个错已经扛了好六年了，一直没有本质的进步。 说明这一技术问题不能仅仅通过单纯的“区分责任”的管理方式来解决。 例如，当您需要重新部署一个包含数百个进程并分为数十种不同类型的服务的系统时，您可能需要小心处理数十个或数百个配置和操作命令。 这种配置和命令有很多相似之处，有些地方需要仔细辨别优缺点。 另外这个配置里面有很多相互关系，大家一定要理解的很清楚，并且对这个配置和命令的执行顺序有严格的要求。 部署所有这些就像操作带有数百个按钮的机器面板。 最可怕的是，其中任何一个出错，系统都可能立即引发“外网车祸”，或者在未来不可预知的时间引发“外网车祸”。 这导致老板半夜三点把你从床上拖到笔记本电脑前来处理这个烂摊子。 其实我说的这种情况并不是每个项目都会发生，我们确实在很多项目中都不同程度地陷入了类似的陷阱。 不知道我们是不是已经被复杂的httpd征服了。 conf，所以很多程序员都非常喜欢配置文件。 “一切都应该是可配置的！” 不仅成为了我们的口号，也成为了无数复杂的配置项和花哨的工具命令。 ——但这种事情，在实际的商业运作中，却成了无数的定时炸弹。

【程序员爱配置文件】

手动测试已成为当今开发的标准程序之一。 尤其是在敏捷开发方法盛行之后，最重要的实践之一就是手工测试。 我们知道，通常我们用于测试的环境往往与真实环境不同。 例如，我们在做功能测试时，运行被测程序的显存和硬盘可能比实际运行环境要小很多。 如果我们的程序因为硬件或者IP地址等其他软件的不同而需要配置运行，那么我们的每一个测试都可能需要手动操作。 不能说是“自动化”。 再加上人为失误，更容易导致测试结果出现严重错误。 测试工作不仅环境不同会造成运维操作，自测也需要多个环境。 比如很多系统有多个分支同时开发，或者有内部功能测试、外部邀请用户测试、公开测试等多个测试环境。 假设我们的软件每次部署都需要大量的人工操作，面对多种环境，频繁发布新版本进行测试，那么部署工作一定是非常繁重的，而这种繁琐的工作本来是可以尽可能避免的。

【一个漂亮的CI闭环，往往毁于复杂的部署流程】

快速发展仍然是现代软件公司追求的目标。 由于不断变化的需求和市场，软件产品和应用系统也被迫每晚更新其功能。 说到服务器端软件，我们在开发过程中往往需要和很多其他程序一起开发调试。 最典型的就是与客户端软件进行交互。 假设每一个参与项目的程序员都集中连接到一个开发服务器进行调试，必然会产生各种相互影响。 而这些跨机开发环境往往只有一些命令行界面，效率不如图形界面的IDE软件。 假设我们开发的程序，尤其是服务端软件，可以直接在开发的工作机上运行和调试，这样不仅响应速度更快，而且在多个程序同时运行时也可以方便调试时间，这对于经常因“联调”而头疼的工程师来说，是一种非常有效的提高工作效率的措施。 但是上面提到的这些方法都需要我们的服务端程序，可以很方便的部署到各种环境中。 另一方面，有些服务器系统结构比较复杂，需要启动很多进程，很多配置文件可以配对启动，所以你肯定懒得部署很多套，而是挤在一个环境里为了发展。

分布式系统运维友好性难点

避免资源泄漏。 我们知道服务器端程序需要常年运行，我们非常担心资源系列，比如显存漏洞、文件句柄漏洞、网络连接相关漏洞等等。 所以很多时候，我们愿意在服务器一启动的时候就“占用”或者“分配”所有需要的资源，然后不管后续请求进来多少，做什么事情，都完全没有必要了。 “分布”，从而避免一切“泄漏”。 但是这种方式也大大增加了程序运维的复杂度。 首先，我们无法明确硬编码一个程序运行的硬件资源。 相反，我们设计诸如配置文件和命令行参数之类的东西来根据运行环境来确定可能使用的硬件资源。 比如我们会在配置文件中设计一个“网络契约缓冲区大小”配置项，根据服务器的显存大小进行配置。 此外，程序中的功能可能非常复杂。 如果要将使用的显存、文件等所有资源都变成配置项，那么配置文件也必须极其复杂。 如果我们期望运维人员理解这个配置文件，最好还是让开发人员自己运维，因为开发人员有时并没有想清楚这些资源的合理分配——原因是过于依赖这些“预申请”表格被用来拖延解决疑难问题。 避免资源漏洞是一个重要的问题，但简单地将资源申请变成配置文件也会带来另一场灾难。 可怕的是，这些配置文件灾难将支撑多进程协作系统的几何倍数增长。 这些运维复杂度在一个系统刚刚上线的时候其实是可以接受的。 然而，随着系统逐渐变得庞大和复杂，运维工作的难度犹如冷水煮乌龟。 无法清理。 经过3-5年的运行，一些系统已经发展到没有人可以从头部署一个新环境的地步。

快速排除故障。 今天的商业应用系统往往不是一个非常简单的功能体，而是包含大量相关或不相关的功能。 我们最担心的是，这种联动功能，在同时处理上千个网络请求时，如果某部分功能代码出现bug，导致整个系统不可用。 所以我们往往更喜欢构建某种隔离系统，比如在不同的进程中运行不同功能的代码。 这样，借助操作系统工具，就可以很快发现这些有问题的代码。 但是如果真的要将一个系统的多个功能分离到不同的进程中运行，首先会遇到的就是进程间通信的问题。 这个问题是现代分布式系统的核心问题之一，无数的开源软件项目都在试图解决这个问题。 但是不管是使用开源软件还是自己写代码解决，这样都会增加系统的进程数。 特别是，我们喜欢按功能来定义代码和流程，也就是说，在运维一个系统的时候，我们需要面对大量“不同类型”的流程。 而且我们定义的功能越详细，流程的种类就越多，需要运维的流程也就越复杂。 在管理这种进程时，不仅需要配置后面提到的一些性能参数，还需要配置海量的进程间关系。 而这种进程间的关系会随着业务的变化而变化。 对于这些没有具体接触开发需求的运维人员来说，简直就是噩梦。 事实上，一些程序员开始在通信公司工作服务器运维，因此他们非常习惯按流程定义功能，按通信级别组织系统，而随着业务系统越来越复杂，这些工作习惯带来了很多麻烦——每周，可能需要向系统添加新进程，或者调整各个进程的通信关系。 不同的行业需要不同的技术方案，这是理性工程师的看法。

负载均衡。 现代服务器端系统基本上是分布式系统。 即由多个服务器、多个进程组合​​起来提供服务的系统。 为了使该系统稳定工作，最常见的措施是避免过载。 为避免多个进程出现一定的过载，需要进行负载均衡。 为避免同类所有进程过载，需要过载保护。 分布式系统中最常见的配置任务之一是配置每种类型的进程启动的数量以及每个进程的过载保护阈值。 但是在一个有几千个进程，几百台服务器的系统中，要准确填写这个配置其实是非常困难的。 特别是，此类服务器的性能并不像提供商所说的那样一致。 如果需要在集群中增加一些服务器，或者改变（搬迁）个别服务器上的服务，这就更加危险了，因为稍有不慎就可能导致原有的工作系统出现故障。 但是，就像业务需求在不断变化一样，运维环境也在不断变化。 比如搬迁IDC，就是最常见的“折​​腾”。 我们可以编写很多运维管理的工具，试图将这些工作“自动化”。 然而，业务需求不断“折腾”，在一些“开发运维分离”的团队中，开发人员并不是很关心运维工具的开发，因为他们已经被市场和业务人员逼迫不断加班，只求功能尽快上线。 由于负载均衡的需要，由此产生的大量服务器端软件和内部工作量与集群中庞大的服务器数量有关，因此是服务器运维和开发困难的最直接体现端系统。

如何开发一个运维友好的服务端系统

为了让服务器端系统运行良好，我们或许应该采取一些开发措施服务器运维，而不是简单地依靠所谓的“运维”甚至更不可靠的“管理”方式来减少错误和故障。

第一个可以作为参考的想法是“构建具有性能灵活性的系统”。 所以，性能弹性，最简单的说就是我们的服务器进程不需要复杂的配置文件，不需要运维操作，就可以运行在各种性能环境中。 除了监控机器的IP地址、内存大小等最简单的自配置功能外，更重要的是我们对资源管理思想的提升。 因为一个系统要解决的问题可能比较复杂，需要用到的资源也会很复杂。 比如我们需要用显存来缓冲没收的网络包，还需要用显存来存储用户会话数据等等。 如果我们只是提出配置这么一块显存，各种显存容量的配置就会有很多。 但是，我们可以通过构建业务表示来简化这些资源模型。 例如，对于一个在线交互系统，我们可以将资源管理的单位定义为“会话”——每个会话代表一个“并发”服务，每个会话使用多少资源是我们可以设计的，然后我们去关注管理“会话”总数以避免资源泄漏。 实际上，这些“会话”在不同的业务系统中可能有不同的概念和作用。 幸运的是，我们还可以利用面向对象的思想，将此类会话及其相关数据用类和对象进行封装。 这样，我们在规划性能的时候，就不用在程序中四处寻找用到“资源”的机器配置，而只需要抓取一个关键变量即可。 更重要的是，我们可以对“”等关键指标采用“池化”的管理策略，将这些对象的使用变成需要“申请/返回”的机制，从而摒弃“分配”一个的做法大量资源是根据实际需要分配资源。 由于“池”的限制，当资源达到上限时，拒绝进一步的服务请求，解决一些过载问题，同时避免资源漏洞。 保护的问题。 而且，在某些环境下，我们还可以让这个“资源池”更加智能化和弹性化。 例如，当请求压力接近上限阈值时，我们可以开始一些扩容或者上报工作，而不是简单的拒绝服务。 或者我们可以定期查询“已申请”资源的处理情况。 如果发现资源占用时间过长，我们可以清除那些服务请求，这样对于自恢复服务有一定的灵活性。 如果构建具有“资源弹性”的系统能力，这样的进程可以以最小的配置实现自我管理和运行。 从根本上降低了运维工作的复杂度，同时也增加了环境变化对系统的影响。 同时，良好表征的功能代码对于代码的维护和开发也非常有利，可以说是一举多得。

第二个想法是“在功能容器下运行”。 在某个项目实践中，我看到了某个系统，它的每一个流程都包含了整个系统的所有功能代码。 通过启动时的命令行参数，可以指定这个进程需要提供哪些功能。 就运维的便利性而言，这个系统远比需要配置部署各种功能来送包的系统简单。 而且该服务器系统还可以以单进程全功能的形式进行开发和人工测试，在开发效率上具有显着优势。 在JSP/技术的使用中，我们经常会把不同的部署部署到不同的容器（如/Resin等）中运行，而没有完全配置各种容器。 现在仍然有一些系统使用/JS/Lua等脚本语言来编写主要的业务功能。 系统中的流程部署，只要脚本容器（引擎）完成，基本上就是复制脚本文件。 . 在容器技术的支持下，我们不仅可以简化部署的工作，还可以获得一些“热更新”的用处。 对于基于硬件和流量的运维工作，运维人员可以集中精力管理“容器”。 例如，它是一个高度手动的 容器。 用户甚至根本不需要安装和部署任何软件。 他们可以直接上传PHP脚本或类文件来开始提供服务。 服务器系统运行在容器下，也可以借助容器指定的一些通信规范进行一些手动运维，比如手动扩容、缩容、容灾——容器可以自我发现运行状态集群并添加新的运行资源，移除故障（如访问超时）的运行资源。 这也是所谓的 SOA 概念的最常见实现。 从另一个角度来说，如果我们有容器的支持，我们在配置进程的时候就可以简化整个集群中各种关系的配置，因为我们只需要告诉容器如何加入一个目标集群，其他的事情都允许容器与其他集群成员协商配置。 容器不仅提出了统一的功能代码开发环境约束，还规范了运维工作。 这对于需要经常改变服务内容，不断改变运行环境的项目来说是非常有价值的。 在WEB开发领域，容器的概念早已深入人心，因此这类系统应用广泛，运维工作可以专业顺利的进行，并且在领域没有网络游戏这样的“行业标准”，功能容器的概念仍然没有被很多人接受。 很多人还在埋怨自己为什么要给自己戴上这个“枷锁”，殊不知自由总是在束缚下行走。

最后说一下各种运维工具，不管是Chef还是各种非通用的运维部署系统。 如果你只使用操作系统提供的能力，你希望统一管理所有的系统。 难的。 而如果我们在开发的时候充分考虑到系统的运维需求，那么我们可能只实现一些简单的约束，就可以大大提高运维工作。 我想这也是所谓受欢迎的原因。 （来源：汉大）