所谓捷径，在拨开迷雾之后也许都是弯路，但在迷雾中很多人都被蒙蔽了双眼。在穷游的技术架构演进之路上，我们也犯下了一些错误。比如2014年我们启动了穷游SOA服务平台，当初的初衷是解耦并复用API的服务能力，提升项目的协助效率。2014年初时，我们制定了SOA服务平台计划，而且不能影响项目原有的产品迭代计划，大量的代码重构和现有的产品迭代计划并行，为了快速实现SOA平台目标，我们新引进了几名能力不错的架构师，决定由架构师帮助项目完成每个项目核心业务的服务化，并计划在2个月内完成。

那么问题来了，架构师根本不了解项目的业务怎么办？让架构师去了解业务并帮助项目梳理核心业务，然后我们尝试寻求各种捷径，并制定了各种兼容方案，快速实现了我们的SOA计划并上线。由于架构师无法在短时间内非常深入地了解业务，而业务本身也一直有新的变化，API的设计也无法达到应有的高度，且很多实现方式也都是寻求捷径而做的临时兼容方案，于是架构师在API的维护中陷入了疲于奔命的状态，导致服务平台停滞了很长一段时间没有新的起色。

看到这些，我意识到我们犯了一些错误，及时掉头，对SOA平台进行重新设计，让架构师去打造了一个API能力贡献通道的平台，然后由项目中最了解业务的人去设计实现API的开发。随着平台和体系的成熟度，未来让每个人都可以把自己的代码变成一种服务能力接入到服务平台。在SOA服务平台建设的道路上，我们追求的捷径俨然成了一种弯路。

在技术架构的演进之路上，从粗犷到规范，从封闭到开放，需要我们小步快跑，不断推演，经过时间的沉淀、积累与考验，比盲目追求捷径更重要。