准备系统介绍《技术系统规划》，这是第一篇。监控平台、服务治理、调用链跟踪、数据采集中心、自动化运维、自动化测试……想说的很多，但还没想好从何说起。如果说Z平台，可能需要提前介绍一下Y服务；如果说Y服务，可能需要提前介绍一下X知识。思前想后，准备从技术系统入手，这是最容易漏掉的，很基础，但又很重要的“集群信息管理”。由于基础，有些同学可能觉得简单；因为我们工作的公司处于不同的阶段，所以在实施方面，我们会介绍不同阶段的公司应该如何实施。还是一如既往的遵循“架构师之路”的思路：什么场景是什么，为什么用，存在什么问题，共同的解决方案和痛点，不同阶段的公司，不同的实施方案。希望每个人都能有所收获。1、什么是集群？互联网典型的分层架构如下：web-server层service层db层和cache层为了保证高可用，每个site、service、database、cache都会有冗余的实例，组成一个分布式的集群是一个分布式物理形式。好吧，这是一口。通俗地说，集群就是一堆机器，上面部署了提供类似功能的站点、服务、数据库或缓存。如上图所示：web集群由web.1和web.2两个实例组成service集群，由service.1/service.2/service.3三个实例组成mysql组成db集群-M/mysql-S1/mysql-S2的三个实例组成一个缓存集群，由两个cache-M/cache-S实例组成。“集群”对应的是“单机”。画外音：高可用架构详见文章《究竟啥才是互联网架构“高可用”》。画外音：如果缓存没有高可用需求，可能是单机架构，而不是集群。2.集群信息什么是集群信息？一个集群会包含一些信息（数量，这个tm是什么解释），例如：集群名称IP列表二进制目录配置目录日志目录负责人列表画外音：集群IP列表不建议直接使用IP，但建议使用内网域名，详见文章《小小的IP，大大的耦合》。什么时候使用集群信息？很多场景，尤其是在线操作，会用到各种集群信息，比如：自动在线监控日志清理binary和配置备份下游调用（嗯，这是最典型的）这些场景，分别如何读取集群信息？一般来说，集群信息前期都会写在配置文件中。比如自动上线，有一个配置文件，deploy.user.service.config，它的内容是：name:user.serviceip.list:ip1,ip2,ip3bin.path:/user.service/bin/ftp.path:ftp://192.168.0.1/USER_2_0_1_3/user.exe自动上线过程为：从ftp中拉取可执行文件，读取集群IP列表，读取要部署binary的目录，部署binary到线上，并一一重启画外音：什么，自动化脚本部署还没实现？还在刀耕火种运维ssh上线，手动执行命令，一台一台部署机器人？赶紧按照这个方案进行自动化改造吧。再比如web-X调用下游用户服务，还有一个配置文件web-X.config，配置内容为：service.name:user.serviceservice.ip.list:ip1,ip2,ip3service.port:8080web-X调用用户服务的过程是：web-X启动web-X读取用户服务集群的IP列表和端口web-X初始化用户服务连接池web-X取用户服务集群的连接用户服务，并通过RPC接口调用用户服务日志清理、服务监控、二进制备份的过程也和上面类似。3.有什么问题？上述业务场景对于集群信息的使用有两个独特的特点：每个应用场景需要不同的集群信息（A场景需要集群abc信息，B场景需要集群def信息）对于每个应用场景，集群信息是这样写的在“自己的”配置文件中。一句话总结：集群信息管理是去中心化的。这里最大的问题是耦合。当集群信息发生变化时，有很多配置需要修改：deploy.user.service.configclean.log.user.service.configbackup.bin.user.service.configmonitor.configweb-X.config。..在这些配置中，需要修改用户服务集群的信息：随着研发、测试、运维人员的流动，很多配置放在哪里，随着时间的推移逐渐被遗忘，随着时间的推移，一些配置被遗忘了更改和省略。渐渐地，一个莫名其妙的问题出现了。画外音：ca，谁知道如何解决上面的耦合问题？一句话回答：集群信息集中管理。4.如何集中管理集群信息如何集中管理集群配置信息？处于不同发展阶段的企业有不同的实施方式。早期的方案是通过全局配置文件实现集群信息的集中管理。例如global.config如下：[user.service]ip.list:ip1,ip2,ip3port:8080bin.path:/user.service/bin/log.path:/user.service/log/conf.path:/user.service/conf/ftp.path:ftp://192.168.0.1/USER_2_0_1_3/user.exeowner.list:shenjian,zhangsan,lisi[passport.web]ip.list:ip11,ip22,ip33port:80bin.路径：/passport.web/bin/log.path:/passport.web/log/conf.path:/passport.web/conf/ftp.path:ftp://192.168。0.1/PST_1_2_3_4/passport.jarower.list:shenjian,zui,shuaiqi集群信息集中维护后：任何需要读取集群信息的场景，从global.config读取集群信息的任何修改，只需要修改global.config一个global.config会部署到任何在线的机器上，维护管理也很方便画外音：嗯，当然，如果信息太多，global.config也会垂直拆分1.中期计划与随着公司业务的发展，随着技术团队的壮大和技术体系的完善，通过集群信息管理服务维护集群信息的需求越来越强烈。画外音：慢慢来，配置太多了，通过global.config修改配置太容易出错了。如上图，建立集群信息管理服务：info.db：存储集群信息info.cache：缓存集群信息info.service：提供集群信息访问的RPC接口，以及HTTP接口info.web：核心接口集群信息维护后台服务为：InfoInfoService::getInfo(StringClusterName);BoolInfoService::setInfo(StringClusterName,Stringkey,Stringvalue);然后通过服务统一获取和修改集群信息：所有需要获取集群信息的场景都通过info.service提供的接口读取集群信息所有需要修改集群信息的场景都通过info.web操作2.长期解决方案集群信息服务可以解决大部分的耦合问题，但是还是有一个缺点：当集群信息发生变化时，无法反向实时通知follower，集群信息发生了变化。从长远来看，应该引入配置中心来解决问题。关于配置中心的细节网上有很多分析，我之前也写过一篇文章，本文不再展开。5.小结集群信息管理是架构设计中非常容易遗漏的一个环节，但也是一个非常基础、非常重要的基础设施。前期一定要做好规划：传统的集群信息分散管理方式容易导致耦合集群信息集中管理，分为全局配置、信息服务、配置中心三个阶段。该文件正在使用信息管理服务来调查配置中心的使用情况。2、对于自动化运维，你的感觉是：ca，什么是运维，都是研发在线搞专运维，但一直是人肉运维魏在用脚本来实现自动化运维，已下岗。他正在利用平台实现平台化。
