关于SOA管理本身，我实践上在前面很多文章都曾经谈到过，应该是包括了SOA树立前周期和SOA运维后周期两个部分的内容。前期掩盖SOA实施全生命周期，前期掩盖SOA运维监控全流程。而从以后主流的DevOps办法论来看，这两个本身又应该融为一体。

以下是我原来给出的一个SOA管理管控体系构图：

其中在纵向掩盖了SOA从设计，开发，测试，部署，运维，监控的全生命周期管理。同时在横向又从业务，效劳，支撑三个进程域停止展开。

即在有了SOA管理后，做任何一件事你都知道应该遵照什么样的规则来做，这是其一。其二在出现成绩需求决策的时分，你都知道应该遵照什么样的决策流程来决策。在这外面一是触及到业务系统，集成商，甲方信息化和业务部门组织；二是触及到技术标准标准和流程，不只仅是标准，同时包括了流程，例如效劳接入流程，消费流程，接口成绩的剖析和处置流程等。

在整个SOA效劳全生命周期管理中，你一切执行的内容都有章可循，这就是SOA管理。

SOA管理不只仅是前期的效劳运维和SLA管理等，同时也包括了前面谈到的SOA从效劳辨认，定义，设计，开发，测试，部署上线的全生命周期管理标准和流程。而在SOA运维阶段，谈SOA管理的时分首先你要看到关于常规的IT管理和ITIL的内容，SOA实施和树立也需求完全去遵守。

而这外面最重要的几点拿出来说就是：

其一就是效劳变更和版本管理，上线后的效劳如何变更，效劳变更如何停止影响剖析，变更终究是晋级大版本还是晋级小版本，包括效劳停止版本晋级后如何对老的业务系统停止版本兼容等，这些都必须提早制定标准和流程，同时制定变更剖析办法。否则就会招致后续效劳上线版本混乱，无法管理的场面。

其二就是效劳SLA管理，效劳的SLA等级如何停止制定，当出现资源约束的时分如何依据效劳优先级停止效劳流量控制，关于高SLA等级的效劳如何来保证更高的效劳运转高可用性，高功用和冗余等。SOA的效劳监控，效劳告警如何与效劳运转实例，效劳SLA等级亲密结合，这些也需求在前期制定标准和标准。好的SLA管理和监控运维体系，中心目的就是确保SOA平台的高可用和高功用，确保在资源约束状况下高SLA等级效劳的高可用性。

其三就是效劳的形状管理，这个也相对重要，效劳如何从定义设计形状到上线运转，关于上线运转的效劳如何停止下线处置等，这些应该遵照什么样的准绳，关于效劳下线如何停止影响剖析，遵照什么样的下线流程，如何停止例行反省以剖析潜在能够下线的效劳等，这些也必须提早商定并制定标准流程。

最后还有一点就是效劳的安全管理，如何保证效劳运转的安全，效劳如何停止拜访授权，关于有特别要求的效劳如何停止传输安全，数据安全控制，如何停止数据加密处置那么详细的加密和解密规则商定是如何的。关于接入的效劳，在哪些场景下必须启用哪些类别的安全控制。这些也属于我们必须思索的成绩。

微效劳管理概述

在谈微效劳管理的时分，首先还是需求重新回忆下微效劳的概念。

微效劳是指可以在“本人的顺序”中运转，并经过“轻量级设备与HTTP型API停止沟通”。

其中关键在于该效劳可以在本人的顺序中运转。经过这一点我们就可以将效劳地下与微效劳架构（在现有系统中散布一个API）区分开来。在效劳地下中，许多效劳都可以被外部独立进程所限制。假设其中任何一个效劳需求添加某种功用，那么就必须增加进程范围。在微效劳架构中，只需求在特定的某种效劳中添加所需功用，而不影响全体进程。

留意，当我们常常谈效劳的时分，很容易直接想到的就是相似WS，Rest API等效劳接口，由于在SOA架构概念外面效劳即特指这些效劳接口。

而在微效劳架构下，特别要留意微效劳不是复杂的Http Rest API接口。也就是说微效劳本身包括了拆分后的微效劳模块，微效劳模块提供的API两个部分外容。

即微效劳 = 微效劳模块 + 微效劳API接口

也正是这个缘由，我们才看到微效劳管理不能复杂地和SOA管理做同等。比如将微效劳管理复杂了解为相似SOA架构下的Http Rest API接口或RPC接口的管控管理。一个残缺的微效劳管理应该同时包括了传统的软件开发全生命周期管理+接口效劳全生命周期管理的内容。

只是原来的软件系统开发变成了一个个拆分后的微效劳模块开发。

微效劳管理框架

关于微效劳管理，假设我们用这个关键字停止搜索，搜索到的内容主要包括两个部分。

相似Springcloud，Istio，管理平台等软件框架平台内容

相似效劳限流熔断，效劳链监控，安全，日志，SLA管理等外容

当然这两个部分外容本身没有错。但是如今容易形成的曲解的就是将对微效劳架构平台上线后的微效劳运转管控，监控剖析了解为残缺的微效劳管理内容。而实践上我们看到微效劳管理的范围远远超过这个了解。

也就是说软件管理框架仅仅是工具或平台，是执行你制定的策略用地。那么管理本身的关键是制定策略，而不是策略终究是人来执行，还是软件工具平台来执行。

我们举一个复杂的例子来阐明下。

关于管理平台提供了效劳限流熔断的功用，比如并发数大于1万次就停止限流，我们也很容易将该规则配置到管理平台。但是实践管理的关键是制定一个策略，即我们针对不同的业务场景，效劳类型，效劳SLA重要性要求，应该如何去制定合理的限流策略。

不清楚基于什么规则制定策略，在平台上胡乱配置，反而是起到反作用。

再比如你的管理平台同时提供了效劳集成，音讯集成和大文件集成才能，这个是管理平台本身的功用。但是针对不同的业务集成需求，如何制定效劳集成类型，这就是典型的效劳管理要思索的内容。否则效劳虚现类型不对，效劳定义颗粒度不对，都招致效劳运转效率，质量出成绩。

这也正是前面强调的，管理管理工具平台不难，难得是基于什么准绳去管理。

微效劳管理体系架构和实际

下面这本书是我最近购置和阅读的一本书，差不多读到了一半，很多中央有启示，而且外面很多做法实践和我们实施SOA集成大项目中的，SOA管理管控做法分歧。

关于这本书的内容，我前面还会独自整理笔记。

从这本书，可以看到作者对微效劳管理的了解包括了度量，管控，管理几个关键方面，并基于三位一体的思绪完成一个微效劳管理的闭环。

(责任编辑：admin)