《架构师训练营》之技术方案与手段
极客时间《架构师训练营》第四章学习笔记
这一章的学习笔记很可能与课后作业高度重合了，所以我不再泛泛列举各种互联网应用了，就写写我自己所在项目里，架构演进的一些故事吧。当然，我所在的只是一个很小的公司，项目也很简单，并没有发展出令人惊艳的复杂架构，而且很多技术可能就是用错了，雅俗共赏吧。
项目背景
18 年初我所在的开发组突然得到领导通知，要起一个新的 web 应用。当时并不清楚具体缘由，只是隐约听说原先架构成本过高已无力支撑产品上线。我们确实受够了之前那个华而不实的系统架构，但是要自己搭建一套新事物，似乎也是强人所难：除了一些朴素的 java 知识，整个开发组没有一个“粗通”架构的后端；前端也极为原始，几乎没人接触过三大框架——React、Vue 和 Angular；CI/CD，更是无从谈起。然后，领导还是下达了指令，搭建一个叫 E-pub 的招聘系统。（为了避免不必要的麻烦，具体业务介绍我就免去了）
项目初始阶段
项目初始阶段的人力安排是：一个兼职的不写代码的 Manager，以及包括我在内的三个底层开发。组织上的要求是在 AWS Lambda 上跑服务。当时的调研了解到 Java 在 Lambda 上性能很不理想，所以我们选择了 Nodejs 为开发语言。前端是 VueJS，后端框架选择了 ExpressJs，数据库是 AWS 的 DynamoDB（组织上指定的 DB）。一个全栈 JS 的开发项目就这样简简单单地达成了。。。
No. 0
第一版上线
第一个版本的项目并没有什么轰轰烈烈的架构，更像一个用于验证原型的系统，简单的决定了技术栈之后，我们写了一个 JD 页面就上线了（绝大多数代码都是框架自带的）。我们被组织上要求使用 AWS Lambda，所以基础设施上可操作性不大，仅仅订阅了一些 AWS 全家桶的服务就上线了：
- Router53： DNS 服务
- CloudFront：CDN 外加一些简单的反向代理服务
- S3：静态资源托管服务
- API GateWay：网关服务
- CloudWatch：log 收集
得益于云服务商提供的应用，架构还有点像模像样了。
No. 1
第二版
第一版上线后，发现这种架构很便宜，一个月就几十刀的开销，相比之前的项目每月空跑就要大几千刀，所以组织上初步认可了我们的方案，功能一下子就加上来了，连续迭代了几个月。
很快我们发现了一个很大的问题：NodeJS 真难用！但是，Lambda 上跑 Java 框架太重了，也不适合我们。我们把眼光放到了 TypeScript 上，它自带类型系统，还完全兼容 JS，是我们重构项目理想的选择。然后花了几个礼拜时间，我们从 JS 切换到了 TS，还换了后端框架——NestJS。
第三版
完成 JS 到 TS 的重构后，我们的业务还在不断增长。当然，并不是因为卖的好，而是设计者无脑给出了很多需求。这里就不细谈这种烂事了。
很快我们就有了五六个子业务线，开发人员也到了 15 人，各种功能各种依赖被添加到了项目里，Lambda 开始报警了：lambda 的上传 size 有限制，冷启动时间也有限制，我们超标了。拆分后端迫在眉睫：
BFF
由于子系统业务都相对单一，服务拆分倒是不难。我们将之前使用的 Graphql 单独提升成一个 BFF（Backend for Front）层，各个子系统被拆分到了新的 lambda 上。Lambda call Lambda，倒是有了点微服务的味道。
第四版
很快又出现了一个新问题：就是 Dynamodb 并不适合作为主数据库，NoSQL 事务性太差了。
插个小曲，在这一年左右的时间里，我们隔壁小组也进行架构切换（Spring架构）；他们也从几人小组扩张到小 20 人规模的部门级组织（但是组织的规格并没有上升，这里不是重点，随便提提）。恰巧他们使用的是 PostgreSQL，而且很多时候我们两个小组的业务具有高度重叠。我们马上意识到，后端可以互 call 呀。很快我们小组就把一些后台功能逐步迁移到了他们的系统中：
No. 4
之后
项目似乎初具规模了。三个开发组，外加 PM、设计、测试、咨询、销售，当时整个产品部门已经从几人到了大几十人规模。业务变得很复杂，系统间调度时间已经很慢了；Manager 们开始设想着上 Redis、MQ 等应用了。但是，但是！产品卖不出去呀！！！
很快部门被各种拆分，外加不涨工资很多人离职了；几个月内就只剩不到十人，里面还包括三个管理人员。。。这样的系统瞬间变成了几个人的游戏，团队士气骤降至冰点。之后的故事就不讲下了。
小结
作为开发人员，系统设计是一件很让人着迷的工作。但是系统的演进必需依赖业务，在一个空壳系统里，再牛乂的架构设计也没有意义。我们部门的经历是：预算不够瞬间死亡；但是继续支撑下去这个架构真的能用吗？这个系统一直处于部门内部测试阶段，几乎没有什么流量，但是调度时间已经很长了；假如真的卖出去，稍微有点流量，系统大概率会奔溃的。
架构设计是我们每一个底层开发的梦想。但是架构成功与否，最后还是看产品是否能获利；不得不说，在这个时代里技术并不不能决定产品。“懂得技术的本质，但依旧热爱技术”，这才是我们工作中最该具备的品质。
