UnitMesh 架構(gòu)：釋放 AI 編程的全部潛力，程序員將成為代碼質(zhì)檢員？ _mesh

Unit Mesh是一種基于人工智能生成的分布式架構(gòu)，與傳統(tǒng)的分布式架構(gòu)不同，Unit Mesh 中的服務(wù)單元 (Unit) 是由 AI 生成的，應(yīng)用程序中的服務(wù)和數(shù)據(jù)抽象為一個個獨立的單元，并通過統(tǒng)一的控制平面進(jìn)行管理和部署。
在上一篇文章《未來可期的 AI 編程：到底是程序員的終極解放還是失業(yè)的開始？》里，我們介紹了人類食用 AI 編程的考慮要素質(zhì) 。在這一篇文章里，我們將繼續(xù)探索 AI 編程的可能性 —— 一種 AI 編程下的可能性：Unit Mesh 架構(gòu)，大抵也是現(xiàn)階段比較可行的方式。
PS：之所以叫 Unit Mesh，是因為我們寫了一個底層服務(wù)叫，還有參考了Mesh 和 Data Mesh 架構(gòu)理念，所以 AI 取建議我們叫 Unit Mesh 。
Unit Mesh
TLDR 版本
我們初步定義的這個版本（0.1 ，稱之為）的核心三個特性：
開發(fā)者可以通過與 AI 交互，生成一定程度的 DSL 抽象化代碼，然后在 REPL 即服務(wù)上運(yùn)行和測試這些代碼。開發(fā)者還可以將這些代碼提交給 AI進(jìn) 行自動化運(yùn)維，AI 會對代碼進(jìn)行優(yōu)化和調(diào)整，從而進(jìn)一步提高 API 服務(wù)的性能和可靠性。
開始正文的廢話版本。
Unit Mesh 初步 Demo：DSL + REPL = Unit
詳細(xì)過程，見本文的后半部分。
前端頁面：
首先，你需要克隆一下，Unit的代碼：，然后，選擇 -repl 或者 -repl 對應(yīng) 、兩種語言。
然后，按對應(yīng)的運(yùn)行起你的 Unit。
接著，在里讓生成如下的代碼，并點擊 Run 按鈕：
【UnitMesh 架構(gòu)：釋放 AI 編程的全部潛力，程序員將成為代碼質(zhì)檢員？】%spring@RestControllerobject Pages {@GetMapping("/")fun main() = "It works!"}
最后，你就可以得到一個正在運(yùn)行的服務(wù)（該功能還在開發(fā)中）：:8080/，訪問該服務(wù)后，如果的應(yīng)該是 It works 。
PS：這里有一個手動加入調(diào)用類和調(diào)用 main 方法的代碼，因為需要做靜態(tài)分析，才能確定使用的框架，暫時沒寫在 Unit代碼中。
Unit Mesh 架構(gòu)
再重復(fù)一下定義：
Unit Mesh是一種基于人工智能生成的分布式架構(gòu)，與傳統(tǒng)的分布式架構(gòu)不同，Unit Mesh 中的服務(wù)單元 (Unit) 是由 AI 生成的，應(yīng)用程序中的服務(wù)和數(shù)據(jù)抽象為一個個獨立的單元，并通過統(tǒng)一的控制平面進(jìn)行管理和部署。
Unit Mesh 核心思想：AI 生成的代碼即 Unit
Unit Mesh 是圍繞于 Unit 為核心的架構(gòu)模式。
碳基嘛，就適合當(dāng)一個。
Unit Mesh 架構(gòu)核心要素
結(jié)合我們設(shè)計的 Unit ，我們設(shè)計的 Unit Mesh 架構(gòu)由以下三要素構(gòu)成。
語言與框架的 DSL 抽象：封裝不穩(wěn)定的抽象
由于 AI 生成的代碼會有各種問題，諸如于無法對接內(nèi)部的云平臺、出錯的等等，所以我們要設(shè)計領(lǐng)域特定語言來解決這個問題，并封裝抽象。
簡單來說：我們需要抽象將所有不穩(wěn)定的元素，便能構(gòu)建出穩(wěn)定的元素。
詳細(xì)的設(shè)計會在后面的 Unit部分展開。
PS：而由于大語言模型是有上下文能力限制的，像我這樣的、搞不到充值的就只配 4k 。因此，我設(shè)計的 Unit 要稱之為 4k Unit Mesh，我設(shè)計的 DSL 要稱之為 4k Unit DSL，有的人可能就是 99k DSL 。
REPL 即服務(wù)：AI 代碼修復(fù)師的日常
在有了 DSL 之后，我們還需要一個 REPL （Read-Eval-Print Loop）服務(wù)，能直接運(yùn)行起 AI 生成的 Unit，然后讓人類來測試生成的代碼是否是正確。如果生成的 AI 有錯誤，就需要 AI 代碼修復(fù)師來對代碼進(jìn)行修復(fù) 。
而對于一個服務(wù)來，如果我們是一個 API，就需要是服務(wù) ，這就是為什么我們在圖里稱之為：REPL 即服務(wù) 。詳細(xì)可以參見后面設(shè)計的 Unit。
AI 設(shè)計的適應(yīng)性結(jié)構(gòu)
人類設(shè)計系統(tǒng)的一個缺點是，如果設(shè)計時、開發(fā)時、運(yùn)行時的單元不一樣，那么就會出現(xiàn)各種疑慮。于是sql server數(shù)據(jù)庫操作工具，我們會偏向于設(shè)計成三態(tài)一致的架構(gòu)模式，而這本身對于架構(gòu)的適應(yīng)性優(yōu)化就是個問題。
而既然，代碼都是 Unit 。那么，設(shè)計時可以是微服務(wù) ，開發(fā)時可以是，線上可以是單體。正如的Waver 所做的事情，我們不決定運(yùn)行時的架構(gòu) ，讓你來選擇。
所以，AI 怎么運(yùn)行我們的 Unit，就讓 AI 來決定吧。
PS：本來吧，標(biāo)題應(yīng)該是適應(yīng)性架構(gòu)（），但是我想了想就只是代碼結(jié)構(gòu)之類的，又重新考慮了一下。
Unit Mesh 設(shè)計心得：反直覺才是出路

文章插圖

文章插圖
在去年年底，研究低延遲架構(gòu)之時，便被這個領(lǐng)域的各種反直覺架構(gòu)模式所震撼，諸如于：GC 是問題那就不要 GC 。
因此當(dāng)設(shè)計 Unit Mesh 時，我們的問題依舊是：如何 Open your mind 。即拋開現(xiàn)有的思維模式和固有知識，打破常規(guī)思考，所以我們的主要挑戰(zhàn)是如何拓展思維，開放心智。
要點 1：如果分層架構(gòu)是瓶頸，那么就不要分層架構(gòu)
在那篇《未來可期的 AI 編程里》分層架構(gòu)是我們最大的挑戰(zhàn)，于是，提出理想的方式就是+ FaaS 的方式，而這種方式則是基于現(xiàn)有的械，又過于理想化。
而隨著我們寫了之后，我們發(fā)現(xiàn)，還可以 Class as a的方式嘛（手動狗頭）。
既然我們的代碼運(yùn)行在云端，由 AI 生成的，那么人類還要看代碼嗎？人類要在什么時候看代碼？無非就是檢入的時候，還有審查架構(gòu)的時候，所以只需要在審查的時候，生成架構(gòu)不就行了。
示例：我想分析 xx 服務(wù)的調(diào)用情況，以及對應(yīng)的代碼，請幫我調(diào)取出來。
要點 2：如果依賴是問題，那么就不要依賴
我們遇到的第二個挑戰(zhàn)是依賴問題，而依賴是兩個問題：
復(fù)讀機(jī)并不能很好解決問題，所以就要讓 GPT 忘記這些。理想的編程體驗，應(yīng)該是我要用，智能就會自動分析依賴，如IDEA 。所以，我們在中采用了 %樣的magic 語法，以自動解決這兩類問題。
要點 3：如果部署是問題，那么就不用部署
起初在 Unit里，我們把 Unit設(shè)計成了一個類架構(gòu)，所以我們遇到了一個問題：架構(gòu)的成本并非所有的人能接受的。所以，我們只需要在測試 Unit 時，采用作為開發(fā)時，在線上合并成一個單體或者微服務(wù)架構(gòu)，那么就能完美解決這個問題。
而在這時，還需要突破剛才的分層架構(gòu)，既然每次代碼是生成的，那么我們只需要一個包名即可，諸如于： org.. ，所有的代碼都在這個包下；又或者，我們可以通過業(yè)務(wù)進(jìn)一步劃分成不同的包，結(jié)合工具來對代碼進(jìn)行歸類。
Unit Mesh 探索之路：從 REPL 到
上面講的太理論了，來看看我們的探索之路，一共分為四步：
從最小的 Hello, world 開始優(yōu)化構(gòu)建一個 REPL 環(huán)境抽象、簡化設(shè)計 ← 重復(fù) 。接入真實世界的。
詳細(xì)可以查看 Unit和的提交紀(jì)錄。
從最小的 Hello, world 開始
首先，讓我們看一個編寫的的 Hello, World:

@file:DependsOn("org.springframework.boot:spring-boot-starter-web:2.7.9")import ...import java.util.*@Controllerclass HelloController {@GetMapping("/hello")fun helloKotlin(): String {return "hello world"}}@SpringBootApplicationopen class ReplApplicationfun main(args: Array) {...}main(arrayOf("--server.port=8083"))

在這個示例里，你會發(fā)現(xiàn)一系列的無用代碼，依賴信息、信息、main 函數(shù) 。而作為一個 4k Unit Mesh 的創(chuàng)作者，我必須把這些不穩(wěn)定的無用信息去掉，才能正確運(yùn)行，所以它變成了：
%use spring@Controllerclass HelloController {@GetMapping("/hello")fun helloKotlin(): String {return "hello world"}}
這樣一來，我只需要讓返回即可。
構(gòu)建 REPL 環(huán)境： + %magic
既然，我們已經(jīng)有了一個簡化的 DSL，接下來就是引入來構(gòu)建一個 Unit服務(wù)器sql server數(shù)據(jù)庫操作工具，也就是我們的：。
Unit的源碼是基于API 所構(gòu)建的，而則是封裝了的 REPL 環(huán)境。我們之所謂基于而不是REPL 的主要原因是，可以使用 magic 和 DSL 來抽象細(xì)節(jié)，諸如于：

"spring" to Json.encodeToString(SimpleLibraryDefinition(imports = listOf("org.springframework.boot.*","org.springframework.boot.autoconfigure.*","org.springframework.web.bind.annotation.*","org.springframework.context.annotation.ComponentScan","org.springframework.context.annotation.Configuration"),dependencies = listOf("org.springframework.boot:spring-boot-starter-web:2.7.9")))

即可以自動添加的依賴和信息，就可以支持步驟的 Hello, World 方式。除了，我們還需要其它的庫的 magic 。
最后，再使用暴露出這個接口，以提供給使用。
抽象、簡化設(shè)計 ← 循環(huán)
當(dāng)然了，只是有一個 hello, world 是不夠的，所以我們需要更多的例子，諸如于接入數(shù)據(jù)庫。而由于的掃描機(jī)制影響，外加我們并不想（主要是不會）針對做太多的特化，所以我們換成了里 Kotr 框架。
PS：值得注意的是，我們還需要對框架進(jìn)行抽象，但是 Ktor 對我們預(yù)期的好一點。所以，我們的第二個版本來了：

%use kotless%use exposeddata class User(val id: Int, val username: String)class Server : KotlessAWS() {override fun prepare(app: Application) {Database.connect("jdbc:h2:mem:test", driver = "org.h2.Driver")transaction {SchemaUtils.create(Users)}app.routing {post("/register") {val user = call.receive()val id = transaction {// Insert the new user into the databaseUsers.insert {it[username] = user.username} get Users.id}val newUser = User(id, user.username)call.respond(newUser)}}}}object Users : org.jetbrains.exposed.sql.Table("users") {val id = integer("id").autoIncrement()val username = varchar("username", 50).uniqueIndex()override val primaryKey = PrimaryKey(id, name = "PK_User_ID")}

在這個版本里，我們使用了作為數(shù)據(jù)庫的 ORM，使用 H2 作為數(shù)據(jù)庫。當(dāng)然，要拿這個代碼作為 Unit 還差了 10% 的距離，不過，基本上已經(jīng)可以解決大部分的 CRUD 場景。
PS 1：這里的只是一個 AWS的抽象，并不影響我們的操作，我們可以直接封裝一個的類，就是懶。
PS 2：我們只需要通過靜態(tài)分析拿出中的代碼，再優(yōu)化即可。更多的探索過程代碼可以見：。
一個真實世界的
現(xiàn)在，讓我們來結(jié)合 AI 跑一下：

請幫我使用 Ktor + Kotlin + Exposed 實現(xiàn)一個用戶注冊的 RESTful API，要求如下：- 涉及到數(shù)據(jù)庫的地方，請直接使用 Database.connect 。- 只返回核心邏輯 ， 并寫在 Server 類里，我要部署在 Serverless 服務(wù)器里 。- 請使用 Kotlin DSL 的方式編寫代碼 。- 不返回其它的無關(guān)代碼，如：注釋、依賴、import 等 。最后，你只返回類的代碼，返回格式如下：

class Server : KotlessAWS() {override fun prepare(app: Application) {Database.connect("jdbc:h2:mem:test", driver = "org.h2.Driver", user = "root", password = "")transaction {SchemaUtils.create(Users)}app.routing {{{{}}}}}}

人生苦短，歡迎加入我們的，一起討論未來。
## Join
狗頭，現(xiàn)在工程師們，你可以就加入 Unit Mesh 的：
本文到此結(jié)束，希望對大家有所幫助。