Serverless 架构：享受纯粹的编程乐趣

王晓波 / 同程旅游首席架构师

专注于高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计，基础云相关技术研究，对 Docker 等容器有深入的实践。

前言

随着公司体系的不断庞大，各种服务越来越多，程序员往往需要操心很多代码以外的事情如资源申请、环境配置、性能安全等，导致了开发效率低下。在ECUG 10周年的大会上，同程旅游的首席架构师王晓波分享了同程旅游从传统架构转变为微服务架构，再从微服务架构转变为Serverless架构这个过程中的一些经验，旨在让程序员的开发能更加纯粹快乐，专注于代码。

---

很多人说OTA这个行业不是互联网，其实确实很难把旅游这事完全的互联网化。如果你去买一个充电宝和买一个帽子，不论是在淘宝还是京东，肯定是一套系统帮你服务的。但是如果在同程上面，你去买一个酒店或者买一张门票，可能有五六套系统在为你服务。这是因为数据、关注的点、用户的行为，完全不一样。导致公司里几千号程序员，每天好像都在干重复的事情。怎么改变这个事情呢？让编程更快乐一些，更纯粹一些。

同程实践Serverless的背景

从一条SQL到一个服务的距离到底有多远？

很多在做业务级开发的同学，往往每天应对的是从数据库或其它数据存储的地方，用一条SQL把数据搬出来，或者写进去，并且把它作为一个服务提供出去。那这样一件事情到底离一个服务有多远？其实真的很远。换句话说就是，当你想开发一个功能的时候，这个功能什么时候能够上线？当我们去做一条SQL时，首先要知道DB在哪，要知道它的性能怎么样，然后得去申请一个工程来放代码。申请了工程之后，得去构建开发环境；构建了开发环境后，得申请线上的资源；申请了资源之后，要去申请部署；部署完之后，要去申请运维。这一切都好了以后，还得想到哪一天要是压力扛不住了，或者哪一天流量大了以后怎么去扩容。当看到这一系列带来的问题之后，一条SQL到一个服务的距离到底有多远？非常远。

在同程，很多的产品经理充满想法。可能早上在公交车上被人撞了一下，就想到一个想法，然后到公司让程序员把这个实现了，下午就要上线。程序员说这个下午上不了线，做各种的解释，说需要申请服务器，或者其它的各种资源。这一系列的事情，其实都来自这个问题：一条SQL到一个服务的距离到底有多远。如果这个时间只需要1小时的话，一天8个小时允许产品经理想8个问题了。晚上下班以后加班4个小时，还能够再想4个问题。产品经理开心了，这样程序员的开发一定是更加快乐一点的。

哪些因素影响着程序员不快乐

• 环境、框架、依赖

首先是环境、框架、依赖，这些问题非常的难搞。

第一个是指环境，从开发到上线这个过程中，环境就已经非常难搞了。可能在开发同学的本地是好的，但到了测试手上或者线上的时候，就出现了问题。闹了半天可能是怪我们的运维同学太弱了，配的环境跟本地开发环境不对，所以不行。其实这里有很大的问题，这个运维同学是背锅的。环境的一致性我觉得本身就是程序员应该做的一个事情。可是并不是所有的程序员都是好的程序员，并不都是全栈工程师。他可能会写代码，但不懂运维，不懂得如何让代码在环境中更好地跑起来。再反过来说中国有多少的全栈工程师？一个全栈工程师的培养又需要多久？这里困难就来了。

还有一个困难就是依赖关系，这也是开发过程当中非常头疼的问题。我自己是个Java程序员，有时候自己写个一两千行代码，只有一两个文件，打一个包，60几兆出来了，一堆依赖关系。当然现在用Go好一些了，但这样的问题能不能解决？比如说同程很多的同学，我们在苏州，北京也有一些开发，在苏州我们有近千名程序员。当有这么多程序员的时候，如何让这些程序员的效率更好地提升？当然你可以用管理，用开发模式去做。但是用技术去解决依赖关系，让没有依赖关系产生不是更好？即使有依赖，也是用接口的形式去调，这样就舒服多了。

• 部署、运维、扩容

还有一块就是部署、运维、扩容。刚才说过可能开发的同学不是太懂运维，运维的同学又不是太懂开发，所以导致了问题。同程之前也在推Dev