参加面试时，许多面试官都会问我的项目经历做了什么，在突然提问下，我由于本来口才不佳的情况下，往往回答的不太优秀，所以按文章的方式来，总结一下。
为什么需要上云
在项目1.0.0发布时，初步的架构设计采用的是微服务的模式，没有上云带来了以下的一些问题。
- 部署的复杂度。 每个微服务都是独立出部署包，需要传到不同的机器上执行安装操作，所以每一次的发布时间都非常长。
- 开发环境的恶化。 在微服务模式下，一定会存在多级调用的情况，在开发某一个微服务时，自测过程需要保证上游服务的稳定性，这一点可以mock。 但是，如果多名开发对于同一服务进行重叠开发下，或者对该微服务的上游服务进行改动的情况下，那么一套开发环境就无法满足开发需求了。
- 排障手段的低效。 由于在微服务领域的不了解，没有相关的基础建设情况下，对那个前端一个接口出现了问题，无法快速的定位到具体的微服务，无法快速的定位到具体的运行实例。
- 程序的可用性问题。 当某一台主机宕机的情况下，那么该主机上的服务会停止工作，需要人工进行介入恢复到宕机前的qps水平。
以上三种情况的杂糅，进一步的恶化了整个项目的研发效能，质量等。 为什么采取云化的方案来解决以上问题？ Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。 2021年，云原生已经有了许多演进思路以及指导方案，单人力的情况下，自研开发一套基建不太现实。并且存在自己的私心，想玩玩并且应用下新技术。
云化过程做了什么
大约耗时一年半，将以上功能全部落地。
为什么有指导方案却落地这么慢？ Cloud Native，需要从架构、研发流程、团队文化三个角度来实现，三者需要相互配合，缺一不可。 在演进过程中存在，1) 技术架构带来的效果往往不会立竿见影。 2）文化以业务成功，结果为导向，引起技术需求的优先级无法提高。3）管理侧的支撑力度较低，4）经验不足等问题。
后续工作的一些启发
- 要有一些产品的思维去思考问题，推动一个事情的演进的前提是，你的产品/思路过硬，能够别人眼前一亮。
- 对于问题，一定要刨根究底，任何一点的不清楚，都会在后续的工作给你带来大麻烦。
- 对于方案的讨论，一定是双方站在解决问题的角度上，而不是装。
- 难的不是技术，不是方案，而是人。
小结
以上只是对之前工作的方案的总结，（立flag)后续将发布一些经验总结项的文章。 另外对于项目不管是什么来说，我都比较推荐上云（前提是有相关人才储备）。从我落地的角度来看，对于研发的各个角度的提升都是非常巨大的。
