面向服务的架构中的服务治理

采用面向服务的架构设计的系统,随着服务越来越多, 面向服务的架构也会带来的副作用,会有盲区,也会有雷区

副作用:

1 业务被分成独立的单元,服务高度的自组织性,每个人只关于自己负责的单元,自己提供的服务和引用其他单元的服务,缺乏对系统整体的了解。而对整体视图了解的人相对决定业务的质量。

2 沟通成本比较高,虽然开发可以并行,但是由于沟通的成本,导致效率低下。

盲区:从战略目标到最后业务的实现,由于业务分割成多个独立的单元,每个单元的理解程度不一样,导致最后业务偏离整体目标。例如战略目标是100%,

不同单元的理解程度为90%,如果有5个单元,目标会有90%*90%*90%*90%*90% = 59%

雷区:某一个关键服务不可用,业务流程就会出现问题。服务需要分级别。不同级别的服务要求不一样。

这个时候需要 需要对服务进行治理

首先架构上要合理,需要做到以下几点

架构透明:

一致的技术架构以及编程模型。需要考虑开发工具上(代码自动生成,开发流程上,代码规范上),采用DDD(领域驱动设计)的编程模型,更加透明的解释了业务模型。

让所有的开发人员达到对架构的理解和认同。

各种源数据的展示(比如系统,服务,以及依赖关系模型描述,系统提供了哪些服务,服务的功能说明,服务的接口说明,以及依赖哪些服务,被那些服务依赖等远数据信息)。

让系统分析人员了解服务模型以及之间的关联。

架构控制:

对服务的运行期的情况进行分析和监控。

通过流程来实现对服务的变更进行控制,服务的升级影响进行评估。

架构对齐:

通过实施企业架构,让IT系统机构对齐公司的业务架构。通过企业架构方法(TOGAF)来实现公司的战略和业务与IT系统的建设相映射。

企业架构一种方法论,指导企业如何建立自己信息系统,来指导公司整体的战略。这一块后续专门会进行分析。

原文地址:https://www.cnblogs.com/aigongsi/p/2611911.html