Adol1111

能否增加格式校验的hook

15

## 问题描述 目前apollo只能做一些简单的格式校验，但很多时候，数据本身是带有一定的格式要求的，特别是一些复杂的json、xml配置等等。目前只是对json、xml本身进行了校验，但是没有对内容进行校验。如果内容不符合要求，只有运行时才能发现，无法确定配置是否生效了（可能内容有问题，直接被抛弃了）。如果不及时回滚，甚至会发生服务无法重启之类的问题。 对于这种配置文件，目前的方案是使用open-api，单独搭建一个服务，但这样做略麻烦，而且配置地址会比较分散。 ## 建议 增加类似git hook的机制，可以给每个namespace增加一个hook(url 地址)。如果发现有hook，在执行保存前调用一次做一个预校验。还可以增加一个post hook，比如把数据做加密什么的。

memory leak caused by many origin

10

## Issue Description 我的用法是这样的，服务A调用服务B（服务C、D、E、F....都可能会调用B），在服务B中用了 `SphU.entry(resourceName,ResourceTypeConstants.COMMON_RPC, EntryType.IN)`，这本身没有问题。但近期给B服务的其他组件也加上了Sentinel，比如调用DB、redis、甚至是调用其他服务的时候（都在B里面）。上线之后内存增长非常快，基本上高峰期10分钟就会一次full gc，young gc的频次也变得频繁了。  Type: *bug report* or *feature request* ### Describe what happened (or what feature you want) 我看了一下，具体的原因，应该是有多个上游的时候，origin数量过多，导致MetricNode数量过多。但感觉里面有一些设计不太合理的地方，比如以下链路，A->B->redis、DB、....等其他资源。按照我的理解，B有多个上游，通过设置origin进行区分，问题不大。但是B去调用其他资源的时候，由于属于A->B的子链路，会导致B->redis、B->DB也会带上origin，但事实上，这些子链路（EntryType.OUT的时候）的origin应该是自己，这个时候去区分origin没有任何意义，反而会增加统计的成本。 ### Describe what you expected...

I have two project with the same name, but in different group. When I run "delete_mirror.sh --delete xxxx", the project which in another group not Mirror group is deleted. I...

feat: support generate doc with additional_bindings

1

fix: https://github.com/google/gnostic/issues/345

FIX https://github.com/google/gnostic/issues/372