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

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

副作用：

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

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

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

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

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

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

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

架构透明：

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

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

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

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

架构控制：

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

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

架构对齐：

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

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