[Day 1] 微解封 微服务 那你有听过微框架吗? 又为何我选择 Ktor?

自从微解封之後，现在「微XX」已经成为流行语，原来 Web 後端流行的「微服务」架构已经超前部署好几年了(误!)。相对於微服务熟为人知，「微框架」这个词就没这麽多人听过了。微框架与微服务的「微」字，表面上看起来都是代表包含比较少的功能，但再深入探讨其意义，微服务着重於拆分系统功能及权责，其结果就是一个功能较少的服务。微框架则是核心功能仅包含处理 HTTP 请求与回应，如果需要其它功能才加进来，所以微框架的特性刚好适合开发微服务，拥有轻量及简单快速开发的优点。

在 Java 的世界中，最不缺的就是框架，其中 Spring 框架生态系最为完整，号称「全家桶」，什麽功能都已经整合进来有解决方案，所以是最多人选择的框架。不过既然 Spring 被称作「全家桶」，自然就不会有人把它分类为微框架，但这不代表 Spring 不能用来开发微服务，因为「微」这个字是有程度差别，是互相比较而来的。虽然每个人的评断标准不尽相同，但我们一般可以根据「核心功能大小」、「启动速度」及「记忆体使用量」来比较。

由於我是因为想学 Kotlin 而想做一个 side project，在挑选 Web 框架时就不会受限於工作上的现实考量，想选择与过往开发技术差异较大的框架，跳脱过去的思维与习惯，所以我最後选择 JetBrains 开发的 Ktor 框架，原因是 Ktor 拥有这些特点:「微框架」、「100% 纯 Kotlin」、「DSL 风格」、「Not Based on Annotations」。以微框架而言，Ktor 真的是一个非常「微」的框架，这是因为 Ktor 强调以 unopinionated 的原则进行设计，没有内建 DI 及 ORM …等常见功能，比起我曾经使用过的 Spring Boot 及 Play 更加地轻量。架构上，Ktor 允许开发者实作 Plugin 进行扩展，透过把 intercepting function 加到 request pipeline 的方式，增加功能或改变框架行为。这种直接传入 lambda 的写法与主流 Spring 框架要求开发者实作特定介面或继承特定类别，再透过 DI 注入的方式有所不同。

总结以上，我的 side project 目标就是根据我过去多年的後端开发经验，基於 Ktor 设计实作自己理想中的 Web 框架，开发一个後端服务，实作范围包含以下项目

• 基於 Ktor 实作支援模组化开发的 Web 框架
• 实作 Ktor Plugin 整合第三方框架及函式库，包括 DI, ORM, Redis Client...等
• 实作 Ktor 缺少的套件来强化 Ktor，包括 i18n, OpenAPI Generator...等
• 实作「User Login Authentication & Authorization」、「Multi-Channel Notifications」…等功能

截至目前为止，codebase 累计已有 241 个 kt 档，不含空白行超过 13000 行。专案程序码在 GitHub => multi-projects-architecture-with-Ktor

接下来的 30 天，我会把文章重点放在说明我的设计概念与实作技巧，不重要的实作细节将会被省略，所以比较适合已经有开发经验的後端工程师阅读，如果您有任何建议或指正，欢迎您留言互相交流。