企业mashup应用的创建是否会对于SOA治理造成影响？我们是否应该留意那些利用我们的服务和/或API创造mashup的人呢？（不论是企业内部还是外部的）

　　运行时SOA治理必须要留意，不仅是企业mashup的创建，还有任何新服务消费者的创建。打个比方，考虑一种DoS（拒绝服务）袭击。这种袭击只不过是一个或者多个我们不期望的“新的”消费者的服务需求泛滥。然而，企业mashup应用或者其他消费者可能不是恶意的，就像DoS袭击，这个比方主要是为了突出一点，也就是如果你没有注意到运行中新的消费者会发生什么。

　　这不是个新问题。早期Web应用，我们设计了富有创造性的方式，通过Web服务来让主机功能性可用，像屏幕抓取。然而这些方法可能是危险的。在屏幕抓取案例中，这种接口点为人机交互设计的，而不是系统交互，这就构成了风险。我们善意的应用积极的通过这个“屏幕”进行成百上千次的调用，比典型的实际用户直接同主机交互要多得多。除此之外，Web应用可能直接对客户端开发进行自助服务。

　　这些相同的问题在企业mashup场景中都可能发生。首先，mashup环境可能推进“用你所拥有的做到最好”的方法，再利用现有接口进行交互，不同于服务设计者的初衷。第二，即使他们按计划使用，如果你没有留意与新消费者（mashup应用）相关的用户负载，你也是冒着风险让新的消费者耗尽你所有有效功能，甚至是按照初衷使用这项服务。

　　这里有一些事情要考虑，从而避免企业中这样的问题。首先，尝试为新的消费者定义运行中的流程，服务管理者可以从新的消费者和既定计划中获取预期负载。

　　其次，你必须监控服务使用并留意需求改变。运行中的流程只能为你提供一个估算，对于实际匹配并没有担保。

　　第三，要根据服务水平协议考虑限流。然而，为了实现这个，你必须能够唯一识别进入的请求源。这一步要求确保每一个新消费者可以唯一识别，没有任何一个其他挑战者的请求可以伪装（意外或者恶意）。

　　最后，你应该在快速增长、各种用例、公共访问或者其他的因素构成的风险中，为了服务的弹性功能而奋斗，这些因素对于正常运行中的流程中进来的所有新消费者可能构成挑战。不管是通过云提供者或者通过你自己的自动化应用基础设施，向上和向下的扩展能力是为了符合动态需求，从而避免运行中断。这并没有意味着要消除监控和运行时行为治理的需求。这里也有空间可以进行优化，通过定期监控产品流量，你可以识别和改进这项服务。