下载掌阅APP，畅读海量书库
立即打开
云计算服务数以万计的企业客户，可靠性要求很高，而系统可靠性来源于系统维护，系统可管理性是系统成败的一个关键因素，从另一个角度来讲，系统可管理性决定着系统可靠性的实现，假如一次维护需要中断服务1min，那么要达到99.99%的可靠性，系统一个月可以维护4次，系统只要保证运行一周多不出问题，可靠性就能达到99.99%，而如果一个系统维护一次需要中断服务20min，系统需要保证正常运行5个月才能达到99.99%，难度可想而知。因此，可管理性是系统高可靠性的一个关键点。
在做架构设计时，要考虑系统维护周期，维护周期长短、维护时服务中断时间等因素是决定系统可靠性的时间指标。通常在架构设计时需要考虑以下因素：
（1）系统中各通常服务器维护流程。
（2）系统中各通常服务器维护周期。
（3）最长维护路径。
（4）各环节需要时间。
（5）通过何种方式保障维护时系统服务中断时间最短或不中断服务。
根据这些需求及架构设计的部署设计，使用路径覆盖方式，估计出系统维护中断服务时长。一般来讲，UNIX/Linux服务器需要在3~6个月重启一次，而设计服务程序要根据实际情况决定服务重新启动时间，以保证系统服务安全可靠。
在系统设计时明确维护周期及每次维护服务的中断时间，并根据维护需求设计维护系统，提供给技术运营人员合适的系统接口，以确保维护实施一致性，减少人为因素导致系统服务中断，对于达到系统可靠性和降低技术运营成本都很重要。
生产线运营的理想情形是在不中断系统服务的状态下进行维护，这一般可以通过备份系统实现，如前面提到的灾备系统。当系统需要升级或维护时，先将系统切换到备份系统，然后对当前系统进行维护或升级，这样服务中断时间就降低到切换时间，如30s，极大提升了系统可靠性，这是云服务常用的维护模式，在架构设计时要加以考虑，最好能无缝切换，不中断服务。
云服务系统配置相对复杂，升级与更改配置都不是一件简单的事情，因此，在架构时尽量设计易于系统配置与升级的API与界面，并建立集中式的配置管理系统来管理不同层次配置，来提升系统可管理性。
集中式的配置管理系统可参考本书的第3部分“服务的技术运营”。
好的医生总是建议患者提前保健，而不是看病吃药。对于云服务生产运营来讲，是要将系统问题消灭在萌芽状态，而不是等到系统出错、服务中断，导致客户不满或流失。如何检测系统是否处于健康状态，也是维护服务人员关心的事，对于人来说，使用各种仪器体检能检测出健康隐患，而系统监控如同各种医疗器械一样，能提供各种系统参数，用以诊断系统隐患，因此架构时设计系统监控系统，对云服务非常重要。
监控应该覆盖平台的所有资源，包括应用服务的状态、应用服务涉及的相关软硬件资源等。对于云服务，几乎所有功能都涉及网络，网络状况监控可以使用SNMP，对流量、丢包、抖动等基本网络参数，以及路由、交换、服务器等物理设备的运行情况及拓扑变化情况进行监控。
服务器运行情况监控，主要是对服务器硬件如CPU、内存、硬盘等情况监控，可以通过如Nagious这样的监控工具提供实时数据。
监控系统的几种展现方式如图3-15~图3-17所示。
图3-15 服务系统运行状况图：可用性数据及报警统计
图3-16 服务系统运行状况图：按照时间体现的运行状态
图3-17 详细警报日志
应用层监控涉及的因素更多、更为复杂，需要在设计应用程序时就考虑监控要求。例如系统需要通过连接池同数据库连接，连接池的健康程度，如当前连接健康情况，需要提供专门的监控接口。服务负载，包含处理并发等情况也需要监控，这些都需要在设计时考虑，而服务一旦构建，再开发难度就相对较高。
因为监控的重要性，第19章专门对监控进行讲解。
应用监控的因素很多，而采用日志方式，将系统运行信息输出，用于检测系统情况或判断问题都是一个简单易行的方式，因此日志系统需要在构建时设计，一个完善的、健全的日志处理机制对系统维护与排除都十分重要。
了解日志机制，首先要理解日志的重要性。在云服务应用中，日志包括以下几项作用。
（1）系统运行和服务状况分析，例如通过Nginx的访问日志可以粗略地估计访问量，对Jboss的错误日志进行分析，可以及时发现潜在问题。
（2）用户行为分析，通过日志跟踪，可以挖掘出用户的使用习惯和操作轨迹，为设计测试用例及提供附加服务提供直接依据。
（3）生产环境问题分析，用户使用过程中会反馈各种各样的问题，日志为快速地定位和分析这些问题提供最直接的信息。
（4）提供历史证据，对一些关键业务操作进行日志记录，用户在需要时可以对这些操作进行查证，最典型的就是用户的误操作。
基于互联网服务架构的应用，其生产环境都相对复杂，每个层次都有很多日志，有的日志由各类服务器提供，简单配置即可，有的日志需要开发实现，下面列举几种常用的日志。
（1）操作系统日志：如Linux kernel日志（系统的dmesg）。
（2）基础服务日志：如Linux xinetd、ssh、bash等基础服务日志。
（3）专用服务日志：如Nginx的访问日志和错误日志、Jboss的应用日志、数据库层的SQL日志、各类资源的运行日志等。
（4）业务服务日志：开发业务的操作日志、错误日志、服务开销性能日志等，一般需要专门开发。
完善的日志机制必须支持不同级别的日志，如Linux log系统支持Emergency、Alert、Critical、Error、Warning、Information、Debug等7个级别的log，用于不同情况，在设计log系统时必须考虑区分不同级别，以方便控制log输出，一般服务器在运行时会打开Information级别log，debug级别的log一般用于研发排查问题。
log系统必须能支持配置输出到不同位置或系统，如输出到文件、数据库或是log监控系统。此外通过配置，可以实现不同级别log到不同系统，以保障系统的运行效率。而log文件的切分、备份等功能都是要考虑的因素。
log系统的另外一个因素是对服务系统性能的影响，要采用relay系统，保证不影响系统的正常运行，在系统空闲时才考虑将log最终写入，典型的如linux syslogd-ng，就通过relayFS实现这一功能，在保证可靠性的情况下，同时保证系统运行的性能需求。
在原始日志采集之后，需要有一定的策略对日志进行管理。原始日志一般会非常庞大，需要进行历史归档或者二次加工，为日志分析提供更加直接的依据。
日志采集是为了进行分析，并最终为各种决策提供有效的参考依据。日志分析方式很多，这里不做深入讲解。
运营系统会输出大量日志，如果能够监控日志信息，对于判断服务健康状况有着非常重要的意义，因此，对日志实时监控，并根据不同级别日志做不同处理，对于确保系统稳定运行、服务有效稳定是十分必要的。常用办法是将日志输出给Nagios、ELK等监控系统。
对于云服务中的SaaS服务，一般用户使用具体功能，不太关心配置、监控与日志，但对于PaaS和IaaS服务，用户在其上使用的是基础设施和平台的服务，对于相关网络、服务器及服务状态监控、日志、配置都有不同需求，这些功能既是内部服务与支持所需要的功能，又是外部客户需要的，因此，在设计时还要区分这两个方面的需求。