Serverless往事
我想单独开一个叫《Serverless往事》的topic，讲述从2018年年初开始我们“艰难探索”新架构的一些故事。Topic会不定期更新，希望能一直更新到一个大型网站的面世。
背景
18年初，突然得到领导通知，要起一个serverless的web应用。当时并不清楚具体缘由，只是隐约听说原先架构成本过高已无力支撑产品上线。一番调研后，海外的某个组首次实践了serverless并获得巨大成功。大中华区CEO很快通知我们，要在中国推广aws serverless。
当时的情况极为尴尬：除了一些朴素的java知识，全组甚至全厂都没有粗通架构的后端；前端也极为原始，几乎没人接触过三大框架；CI/CD，更是无从谈起。最大的困难是：我厂只做B端，对Internet网络攻击毫无抵抗力。然后，我们接到了任务：搭建一个叫E-pub的互联网web应用。一个新时代就这样开始了。。。
业务分析
E-pub是我所在某招聘相关产品组的一个子模块，主要面向互联网端的应聘者。业务流很简单：应聘者通过E-pub录入个人信息，并向雇主申请Job。雇主在企业内部HR系（姑且叫IVF吧）能及时同步应聘者申请。主要页面其实就两个：1. 隐私条款 2. 用户信息录入页面
-
性能
设计之初，我们开发的是ST模式（single tenant）的E-pub。就单个Tenant来说设计用户不会超过1万人。以每天8小时计算，TPS峰值也就个位数，因此性能并不复杂。数据库的话，Dynamodb也能胜任了；Web服务用api gateway + lambda就搓搓有余。因此，我们不需要自找麻烦去讨论MQ、Redis、Zookeeper这类大型应用。
-
可扩展性
E-pub功能很简单，几乎不会再扩展了。
-
可用性
E-pub晚上几乎不会有人访问，即便是白天，宕机几个小时其实也不会有太大影响。复杂均衡、异地多活这类方案就免去了。但是数据丢失可能比较麻烦，因为雇主和应聘者之间本没有联系方式，数据丢失意味着永远失联了。所以搭建数据库的话必须考虑主备方案。
-
安全性
E-pub包含应聘者个人信息，有一定的隐私性；但是不会包含密码、银行账户等信息。只需要控制访问权限并及时清除线上数据就行了。
-
成本
系统很简单，有一个主备从的数据库和一个简单的服务器就能搞定。
技术栈
业务确定后我们立马讨论了技术栈的选择。
-
ExpressJS
我果断放弃了java，主要原因就是冷启动太慢了。E-pub只是先期项目，我们后续有更复杂的业务。当时lambda会在无响应5分钟后自动关机（现在已变）。从我们已有的IVF项目中得出的经验是，Java服务调用➕冷启动很容易突破这个限制。于是我果断选择了node js。其实说来也惭愧，组里除了会java和js，没人会别的语言了orz
Nodejs最出名的框架是Express，它的启动时间极端；后来在生产实践中也得到验证：最慢一次lambda冷启动时间也就800ms。在同期实践的其他serverless项目中，竟然有几十秒冷启动的服务。
-
NuxtJs
前端框架的选择没有争议，国内vuejs具火，我们也不免俗套。由于当时缺少技术积累，我选择了NUXT——VUE的SSR框架。NUXT集成了VUE全家桶里主要的插件，自带webpack，几乎零配置就可以上手。不过后来也被NUXT坑了一把，这是后话了。
-
DynamoDB
DB是Department Manager指定的。IVF系统用了NoSql的cassandra，转到serverless后竟也保持了这种传统（虽然cassandra作为主数据库已被无数人吐槽）。
Architecture Review
两个礼拜后，我旁听了组里领导和arc team的Review，依稀记得对方来了两日本人和一个印度人。不得不佩服我领导，他和对方leaders谈笑风生，独留我一人茫然无知，大概是我听力实在是太差了吧。两次review会议后，E-pub得出了大体如下的框架。
架构很直白，服务部署在lambda上，应聘者只能通过api gateway读取Job信息，并录入个人信息；IVF（对的，是我们的那个内部HR系统）轮询E-pub，同步信息后删除Dynamodb和S3里的记录。
回过头来看，这个设计甚至不如一个学生管理系统复杂，不过在E-pub场景里却是一个很务实的选择。
说点闲话，汉语语境里保守和激进都带明显的贬义性质。很多人喜欢评论别人的技术选型太保守或是太激进，然后沾沾自喜一番。但是评价者自身没有技术判断力呢？架构的选择也是如此，其实并没有保守或是激进之说，简单务实才是最正确的选择。
小结
到此为止我们的E-pub正式进入开发阶段，虽然系统简单但是五脏俱全。之后我们仅仅用了一个多月就搭起了这个web应用，对比IVF年复一年的跳票，不得不说serverless带给了我们巨大的惊喜。总结起来大约有这么几点优势：
-
开发环境：我记得当年首次启动IVF环境花了整一周；E-pub的话，傻瓜操作
yarn dev - 开发体验：启动快、热加载、部署简易
- 开发成本：第一月的消耗只有十几刀，对比IVF系统空跑的成本就是大几千刀每月
不久之后，我们迅速开启了另一个新项目——M-pub。这次挑战更胜从前，更复杂的web安全、DB读写限制、MT、微服务治理、CI/CD……世上并没有一劳永逸的框架，更没有放之四海皆准的技术。我们又该如何抉择，to be continue...
后话
有一次我向某日本领导请教技术栈的问题，她道出了一些很有趣的事。领导们并不关心技术，更不关心开发体验，他们只想要一个低成本的产品。这些话让我茅塞顿开：对于底层小职员来说，我们追求新技术是因为技术是安身立命的本钱；但领导们不是，他们讲的是管理，要的是可控。从某种意义上来说，正确理解领导的意图其实也是我们底层小职员安身立命的技能。
