一、 微服务架构与巨石架构的差异
“微服务”与“巨石架构”两者并非对立，而是分别针对不同场景的解决方案。
巨石架构指将所有“大脑”集中在一起，以CS架构为代表，将所有的逻辑放在唯一应用中，再加入前端UI组件、Service、MVC架构、数据库等部分。它的技术架构不复杂，调试、部署、管理方便，是适用于绝大部分系统的解决方案。
但是在互联网要求“多、快、好、省”的应用场景下，“巨石架构”面临诸多挑战。
多：互联网用户量巨大，达百万级在线量；
快：服务请求反应速度要在一秒以内甚至更快；
好：服务质量稳定性要高；
省：硬件成本增涨要低于用户量增涨速度。
如何解决这四个问题——增强整个平台的灵活性。
平台扩展能力
1.平行扩展：一般的无状态服务器可以通过服务器扩容完成平行扩展；
2.分区：对于有状态的服务可以通过分区增强平台灵活性，如：南北方用户分属A、B不同集群。
平台上的扩展“巨石架构”可以适应，但是功能上的扩展却比较难适应。
功能扩展能力
功能维度上，如何使系统变得更融洽？
1.灵活控制成本：局部调整，变更模块、逻辑，而不是整个系统去修改。
巨石架构的所有模块都捆绑在一起，进行扩展时，由于每个模块巨大，只能高成本平行整体扩容。
微服务架构下模块产品的服务器分布非常灵活，扩容成本低，现在都会选择将服务器模块切分，进行微服务化改造，提升平台支撑能力。
二、微服务架构下如何构建一个运维管理平台
上文讲述了微服务架构与巨石架构的差异，接下来了解如何构建一个运维管理平台。
运维平台管理最重要的是应用。对于应用运维来说，系统的前端所接入的官网、中间的逻辑服务，后端的存储、缓存，分属于不同的运维。
把运维平台拆分成三块具体化部件对应到工作中。
运维平台的内部应用、内部依赖是什么？——程序、配置文件、计算的资源
是什么支撑运维平台作为一个互联网应用？——内存、CPU
运维平台依赖的资源有哪些？——系统镜像
这是CMDB IT资源管理系统要承载的，在自动化扩容、环境部署时，只有了解这些数据，上层系统才知道如何构建这个应用。很多运维团队，仅仅做到“工具化”，却没有跟“资源管理配置”联动起来。
资源有效管理之后，是研发、运维这类的动作管理。如：版本更新，迁移服务、搭建测试环境等标准化的动作。
在拥有资源和动作，达成自动化运维的闭环后。运维人员只需事前维护好准确的资源配置数据（CMDB），余下动作系统会自驱完成。如果把资源跟动作相混杂，每次运用都需要耗费资源定制专用的发布脚本、构建脚本。
除了资源跟动作管理，还有状态（监控）管理。每个公司都会有“监控”系统。这里需要强调的是意识的问题，因为在整个上层、应用层监控设计中考虑了“自动容灾切换”能力，所以我们不需要关注底层的监控。只要应用层没有告警，不用管底层服务器和机房是否挂掉。
我刚参加工作时，系统经常告警，需要半夜爬起来重启机器、删文件。现在运维只会接到通知，告知服务器挂掉，进行确认，不用实时处理。基于这个逻辑，在业务没有告警的情况下，我们系统就是正常的。
完善的运维管理平台能够合理的把资源、动作、状态协调管理。
这张图将上面那张简单的图做了扩展、细分。
最上面是面向运维，包含运维、研发者的服务目录和日常任务中心、状态中心的统一运维门户。
下面是调度编排系统，产品扩展根据不同行业及其业务特性，做出不同编排需求，将这些不同的需求选项进行固化。
中间是运维平台的核心，执行层的系统。忽略灰色的传统API模块，现在我们运维日常使用的就是这个包括持续交付平台、统一监控平台和ITOA运营分析平台在内的立体化监控系统，通过它实现动作、状态管理。针对基础设施、平台系统、应用级、服务级甚至更高层的需求，提供精确度、优先级不同的接口。
底层是CMDB资源管理。传统CMDB管理对象，属于硬件资产。在云化技术发展之后，会越来越弱化。应用运维就不需要关注太多。这里CMDB包含了业务信息管理、应用程序包、配置、定时调度任务、流程、工具、权限、系统配置等基础资源。
三、运维平台的微服务进化
伴随着公司业务的发展，如何将正在应用的系统进行架构上的优化或者规划？
1.技术选型
首先，微服务跟基础架构的区别在于，微服务的组件拆分后是通过网络传输的。因此通讯标准要做出合理的选型。
微服务的架构，通常是异构架构。比如我们的平台运用了Python、JAVA、PHP等语言，必须选择同时兼容多种语言的协议。就像我们之前选用protobuf时，发现Python自带的库兼容Linux系统不成熟。在不同场景下，微服务的技术选型需要有较强的兼容性。
其次是语言的选择。微服务强调接口的稳定性，在保证服务稳定的情况下，可以自由选择熟悉的语言。
2.微服务的规划
单一职责原则：每个服务应该负责该功能的一个单独的部分。
明确发布接口：每个服务都会发布定义明确的接口，而且保持不变，消费者只关心接口而对于被消费的服务没有任何运行依赖；
独立部署、升级、扩展和替换：每个服务都可以单独部署及重新部署而不影响整个系统，这使得服务很容易升级与扩展。
3. 平台构建
通过下面的两个模块来讲解平台的架构。
1） CMDB系统怎样做简单的分拆，使之更容易维护？
CMDB是一个有大量配置系统存在的可以进行查询、修改的数据库管理系统，它的内部包含模型管理，配置管理、自动发现。
A）模型管理
CMDB中，我们会管理大量随着产品技术站演进动态变化的资源和相异的动作，所以要独立出模型管理的模块，保证CMDB动态可调整。
B）配置管理
由于CMDB的信息敏感度高，很多公司要求，将敏感业务信息，特别是应用和IP这类关联关系的信息保存在里面。
C）自动发现
如果CMDB没有完善的自动发现机制，它失败的概率会非常高。就像传统CMDB有一个在严谨的审批机制运行下的配置变更流程。但是即使在配置跟现网一致的情况下，还是需要每半年进行一次资产盘整，对信息进行纠正。对于有海量业务的系统来说，没有“自动发现”能力的CMDB是不合格的
通过“自动发现”，去自动化采集服务器带宽、网卡速度、内存、磁盘空间、进程等信息，由CMDB进行管理。模块管理相对传统，“自动发现”是CMDB的核心，在同时管理数十万台服务器时，只能通过“自动发现”的探侦才能进行自动化维护。
2） 持续部署系统
持续部署系统负责自动化发布。上图将持续部署系统的平台构建分为多个子模块。
A） 构建管理
构建即以静态图片、业务程序、配置文件等为主的部署对象。根据DevOps中的原则，需要将一切版本化。所以需要一个构建库负责管理所有发布到生产环境的资源。
通过统一的构建库，对所有发布到线网上的数据进行标准化管理，以此可以快速在其他机房重建原系统等。同时它还拥有信息共享功能，过去运维发包之后跟踪困难，现在研发人员只需向构建库输入版本信息，运维从构建库中导出就好了。
B） 任务管理
任务库负责存储日常发布任务，满足自动化发布需求。曾经由于很多研发人员贪图方便，选择在现网直接更改系统，记录信息错乱变更很不利于任务管理的日常下发。
常常是错误的，所以我们并不使用“任务下发完成之后，系统设置自动更新”这种设计。在无法信任上层管理系统的情况下，现网信息、数据必须实时扫描上报。
为了保证信息的发布成功，必须以Agent上报的信息为准。因为配置信息存在大量变更入口，在无法保证唯一入口的情况下，不能想当然的设计系统。
命令通道与数据通道是除了构建库、任务库、实例库之外的上层系统的基本构成。首先命令通道与数据通道需要分开管理。腾讯曾经需要将1G的文件发送到两千台服务器，频率达到一周一次，一次一周，不断重试、失败。后来将命令与数据切开，每次只传输几十K的命令脚本，服务器再也没有阻塞。
开源方案部分问题依旧无法解决，像现在的异构网络，在混合云的场景下，必须保证网络互通，才能做到直连。大家可以选择自己去编写Agent练手，通过反向通道连接中心管理服务器去解决此问题。
微服务架构下平台架构的底层基础服务
1.名字服务
名字服务指通过配置文件中匹配的名字查IP端口的服务，可以选择合适的开源方案。如果自研的话，可以对服务进行灵活分区等。如深圳的服务器A访问在深圳、上海两地均部署服务的B，我们只需要在，名字服务中与CMDB打通，使用深圳的服务器访问深圳的IP，达到同城访问的效果。这个操作在开源方案中就无法完美实现。
2. 状态监控
要求能达到接口即调用数据采集的应用层监控。
通过访问量、成功率、平均时延这三个核心指标，低成本把握绝大部分需求。以访问量为例，当访问失败率上升告警时，直接触发名字服务联动，将故障节点自动摘除。
3.负载均衡
当系统规模扩大，节点剧增时，增加中间代理的方法会增加系统内部压力。
如果落地到Agent，通过名字服务查询IP列表，合并状态信息，均衡节点请求，可以更好的达到负载均衡。
负载均衡的极端就是容灾，正常情况下根据性能状况保证每个节点处理合适的请求量即可。
这三点是运维平台或业务生产的系统中的核心能力。包括腾讯在内的运维平台都是基于这三个服务闭环去运行的。只有在做到这三点，才能解决系统异常，维持系统的正常运转。
微服务运维平台的迭代重心
其实我们在平台构建的时候，在整个的平台进化的过程中，其实是要有优先级，要有取舍的。总得来说，优先要解决我们的瓶颈问题。 然后是平行扩展的能力，还有考虑服务复用的能力，甚至是一些开源的解决方案的利用。但是开源这个东西，我从来不觉得是说大家把一堆的开源工具用在一起，能够形成一个很好的一个运维平台。
大家应该是把这些开源的能力，这些一个个的微服务，核心的这个架构还是必须要有自己的控制力在这里。比如：监控。很多开源的系统，它是更偏重于执行层的工具，但是核心的CMDB，核心的流程控制还是需要我们去建设的。
第三十四届CIO班招生
北达软EXIN网络空间与IT安全基础认证培训
北达软EXIN DevOps Professional认证培训
责编：zhangxue
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
