题记：简单梳理下近期的一点工作，遇到一些瓶颈点，有些地方一直是稀里糊涂，没有思考清楚，这里烂笔头写出来，也帮助脑子捋捋清楚。
背景：基于微服务化的业务架构有一个最显著特点：模块众多，交互拓扑异常复杂。而我所在的业务线，大概有300+服务构成，近期工作的一个主要目标：线下一键自动化搭建300+服务，要求单服务有效且整体服务保持联通，也就是线下测试环境的自动化快速构建，主要面向产品技术线研发和测试同学，用于日常迭代的研发及测试工作。
实现方案：单服务容器化构建+服务间通过服务发现自动连通。听上去很简单，且很美好，对不对？可就是这样一件事情，断断续续搞了4个月还没有找到真正的产品的形态。
当前进展：69服务通过容器化搭建，其他70+服务单向连到唯一公共ip，剩余所有服务采用独立机器部署实现。
主要问题：
1. 新增服务未实时发现，需人工补充，成本极高。操作包括建服务，加模板，部署实例。每周均有更新，update成本需0.5day/week；
2. 单服务构建问题，定制化脚本过多，主要集中在：control.sh未对线下仿真集中处理；服务的路由配置定制化开发；服务的配置文件从线上同步工作（diconf）；服务的关键apollo开关配置定制化采集（apollo）；多服务混部，推送过程变为主动拉取，且实现脚本为补丁jenkins形式（彩虹桥）；服务的特殊化处理层不支持，定制化开发supervisor conf文件（walleby）；服务库表结构发生变化，未及时update；上下游交互字段发生变化，未同步更新部署；
3. 服务间拓扑发现问题，部分服务依然采用conf中写死ip：port的方式，不具备自动发现下游服务能力，需使用publishEnv或ans方法接入；
4. 单服务构建描述文件及补丁散落点较多：ac平台，定时脚本在pre机器和sim机器，部分配置在ftp服务器，disf脚本自运维，ans服务，以及ac的jenkins定时任务管理等；
目前的进展一句话总结就是：可在某一时间点一键自动化搭建核心服务，但不具备自动更新能力！
曾经我理解：我们需要推出的是一个平台，以及一系列工具集，可以支持用户打各种补丁。现在看来，这种方式并不友好。目前一代的环境至少给用户提供的是一个完全打通的，稳定的，互联的产品，虽然实时性并不很高。而现在我们所推出的产品，尚未达到阶段性稳定。
理想的：
1. 业务服务的线下环境构建脚本，集成在代码仓库中，平台可自动识别解析；
2. 线下有一套实时更新的环境，与deploy打通，每次代码上线变更均可感知；
3. 搭建平台解析的公共服务统一维护；
Todo：
1. 拉齐各方研讨现状，并制定下一步计划；
2. 应用场景及服务在此基础上持续迭代，制定timeline及周粒度追溯反思结果。
