其实在第一阶段，主要问题不是很明显，但是为了后面能够比较顺利的去做快速迭代和开发。我们在这里引入了一些规范，这样的话为后面的迭代提供一些相关的保障。比如说我们引入了TrackId，因为你后面调用的服务比较多，在这个过程中想跟踪一个调用的走向，直播，包括这个调用在哪儿失败了，在哪里出了什么问题，需要有一个东西串起来，这就需要引入的一个规范，你的服务开发一定要能够识别TrackId，同时不能把它吃掉，你在往下调用的时候不能扔出去。另外就是我们开发的服务一定要支持恢复发布，我们的服务跟传统的ToB不太一样，我们是不能停，也是在线的。我们的恢复发布的要求就是说你要允许这种单点逐步，一个点一个点的发布。另外你设计的服务一定要支持回滚，哪怕你有新的更新，如果在线认证发现问题一定要能回滚。我们这个恢复并不是互联网根据用户的特性进行引流等等，只是为了满足我们的业务在线不中断，能够随时更新我们的业务。

　　顺便说说如何去管理服务调用调试这个问题，在一个版本下面需要保证大家都能够稳定的有一个开发、调试调试环境。所以我们的环境就四种，比较混乱的是本地开发，开发测试环境。相对稳定的是集成测试环境和生产环境。集成测试使大家能够基于这个环境来做上线前的测试、稳定性或者性能上的测试，我们通过这种方式去规避在开发过程中不兼容或者版本混乱的问题。

　　这里来说一下我们之前遇到的问题，首先一个就是上线以后，我们引入了很多的服务和用户。这个过程中我们发现每迭代一次是要接入新的服务厂商，也都要去改这个服务调用网管，去改里面的适配器而不是主要的业务流程。在这个过程中我们发现，我们之前的系统边界没有规划好，频繁变化的地方应该是拿出去的，这个情况下我们就做了一个重构。把适配器这个模块单独拿出去，再接入其他厂商的服务，甚至于同一家厂商不同的服务，我们都在适配器这层去做，而其他的没有任何的影响。我想这块一个是我们自身设计的不太合理，另外一个就是如果要想做基于传统的系统，你想去往微服务的架构上面迁移的话，其实也可以把你系统里面有哪些是频繁变化的东西，单独剥离出来，作为你微服务的开始。

　　在迭代过程中，我们基本上就把主要功能的雏形放出来了。就是基本上每个人负责一部分服务来维持整个系统的一个运行。在这个过程中就开始出现了刚才我说的一些问题了。首先第一个，我们可以看到每一次调用，ES要从Topic里面拿一个，计量模块要通过Topic去读每一次调用的总量，这个过程中ES又要写又要读，你的访问量很小的时候，这完全不是问题。在我们发现我们的业务量增了十几倍的时候，业务调用量大概在千万级的时候，发现这已是一个非常大的问题了，我们每一个主要的模块都有报警。通过一些追查，包括TrackId的追查，最后发现模块实时拿用户的计量数据的响应超时非常多，很缓慢，我们又去看ES里面到底是什么问题，发现了CPU占用基本上把两个节点都已经占满了，内存也是不停的在做服务GC，但是每次服务GC的效果基本上没有，占用率还是在90%多。我们一上来就先扩内存，但是发现扩完内存一样，在这个调用量下面还是不行，CPU的占用率也下不来，我们知道肯定是节点的性能有问题。我们后来又临时马上又扩充了几个节点，暂时把这个问题缓解下来了，勉强撑住用户在这个时间段的一个调用。我们采用了一个临时方法先去解决用户，后面我们也不断的进行重构。

　　另外就是之前比较粗犷式的发展，对我们的资源并没有进行保护。直接造成的问题就是我们上游的数据服务经常会被我们压跨。所以也是给他们弄了一堆包，后面随着我们调用量和用户量的增长，我们也在资源保护这边去做一些事情，比如说过载保护。

　　再回到第三阶段，就是我们后续的规划。我们后续规划基本上是两个，一个是技术方面的，一个是业务层面的。技术层面我们会逐步引入异步的调用，另外，之前我们为了避免风险，我们没有去做服务治理，后面随着我们的服务一点点的增加，特别是这种适配器或者其他功能的增加，你一定要把这个服务治理做上去，否则的话你后面很难谈微服务的灵活部署、微服务拓展，后面的弹性扩展更不要说了，你怎么根据你的负载能够弹性增加你的性能。