而外面触及到的关键就是微效劳度量体系的树立，效劳监控管理（限流，熔断，升级，安全）和效劳链监控。其中效劳度量触及到效劳开发，测试，运维，上线运转各阶段的度量；关于效劳管控本书也触及到微效劳全生命周期的管控。

在该书给出了微效劳管理和微效劳管理之间的关系如下:

从中可以看到度量在整个微效劳管理中起到要给关键作用，即经过度量来完成整个管理和管理进程的闭环，其次是完成管理标准和准绳的继续优化和改良。

网上有一篇文章大家可以参考：

?artid=22256

在该书外面给出了一个管理，管理，度量三位一体的微效劳管理全体架构。

从图中可以看到，微效劳的管理既要停止线上的管理，也要停止线下的管理，经过线上线下两大维度停止管理目的的采集，并把它汇总到数据仓库中，停止一致的度量和剖析。

这些度量目的中，有相当一部分线上的功用及异常目的会被转化为运维事情，一旦触发我们预先设置的阈值，就会被进一步转化成“管控指令”，并经过调度中心下发，停止效劳的弹性伸缩、扩容缩容操作，或许停止效劳的限流、升级、容错、路由调整等管控操作。

另外一部分度量目的，包括架构、开发、测试、运维、进程协作效率等目的会经过管理委员会（泛指，管理成员的集合）停止人为的深化剖析，并制定出管理决策，这些管理决策会经过相关的管理措施停止落地。

重新思索微效劳管理框架

基于前面内容，这两天重新思索了下微效劳管理和管理框架。

关于微效劳管理在前面曾经谈到了实践上包括了微效劳模块本书和微效劳API接口管理两个方面的内容，而不能复杂了解为API接口的管理。因此微效劳管理应该进一步融入IT管理和SOA管理两个部分的内容。

假设重新给微效劳管理一个定义，应该如下：

微效劳管理是针对企业组织和业务目的，制定一套标准的管理，业务，技术，进程标准体系，完成微效劳从需求，设计，开发上线，运转，下线的全生命周期管理才能。同时构建一套残缺的度量目的体系，经过实时的日志和功用数据采集，继续的监控效劳运转监控形状，并执行相应的限流，预警等管控策略，以确保微效劳的继续安康，牢靠和高效运转。

基于这个，可以了解为整个管理框架应该包括三方面内容：

设计态：如何停止微效劳剖析和设计，模块拆分，接口设计

运转态：如何构建度量剖析体系，完成微效劳监控，确保微效劳安康运转

标准类：构建一套残缺的掩盖管理，业务，技术，进程支撑的标准体系

工具类：基于下面管理要求，选择可行的技术平台或工具停止支撑

以上就是一个微效劳管理本书应该包括的片面内容。从这个外面也可以看到微效劳管理平台或开发框架实践上仅仅占了微效劳管理的一部分外容，而不是全部。

微效劳管理概括来说，实践上关键包括两个部分。

即在微效劳需求和设计期是如何停止微效劳拆分，接口颗粒度设计；在运转期是如何基于度量体系停止监控并构成闭环继续优化改良。

基于以上思索，对微效劳管理全体框架停止重构如下：

该图基本围绕微效劳全生命周期管理和基于效劳度量体系的继续运维监控两个方面展开，关于一些二级的内容在该图暂时无法展开，比如常说的效劳版本管理，效劳依赖剖析是微效劳管理的要给关键内容，暂时在该图没有表现。

在运转期还有一个关键思想的转变就是不是复杂的发作成绩缺点后的运维管理，而是应该基于监控预警剖析下的自动的技术运营和SLA效劳等级提升。

【编辑引荐】

将云技术带入数据中心-走向数据驱动型业务的旅程

为什么我不建议在Docker中部署数据库？

2元买上千人脸数据，你的隐私养活了多少人？

卸载Navicat！操作一切的数据库靠它就够了

大数据杀熟或认定为垄断，值得等候

(责任编辑：admin)