LOGO
首页 网站广场 站长动态 活跃度榜 审核查询 逛逛好站 留言交流 提交申请 关于本站

站长动态

站长动态所展示的是已加入好站网成员站长文章
共同步 2384 篇博文
(每2小时更新一次)
陈仓颉
入驻第1年
奥本海默
We knew the world would not be the same. A few people l […]
Holley
入驻第1年
中医学习记录
记录归纳自学中医相关的内容。
JN
入驻第1年
使用 Mastodon(& Liker.social)近一年的心得
終於 先恭喜我自己,加入 Matters 和 Liker.social 將近十個月,終於存滿 5000 LIKE,獲得讚賞公民的資格! 但說實話,LIKE 幣其實對我來說沒什麼具體的意義,5000 LIKE 也就大概 200 台幣吧,最大的功能大概就是可以讓自己繼續被綁在以 LIKE 為核心的生態系。但也無所謂,這不對我產生任何的威脅。 我眼裡的 Liker.social 我覺得 Liker.social 是很奇妙的地方,甚至很難定位它的使用者是怎麼樣的一群人。以我自己來說,我是透過 Matters 才知道 Liker.social 的,所以我預期的是上面的人大部分都在 Matters 上或其他地方有創作,但事情似乎沒有那麼簡單。 以社群網站來說,這個群體其實非常非常小,活躍的使用者頂多就幾百來人的規模吧。大概花個 5~10 分鐘就能看完站上一整天所有使用者的嘟文,也因此很容易和陌生人互動,畢竟常看到的永遠就都是那幾個人 XD,這邊似乎也相對封閉,除了比較常看到的 g0v.social 和一些大大架的私人站點,似乎沒有看到有和其他什麼站點互動。(雖然也有可能是目前繁體中文的 Mastodon 站點不多就是了) 聯邦 is good 我還蠻認同 Mastodon(或者應該說 ActivityPub)這種聯邦式的設計,開源、開放、去中心化這些我就不說了。我覺得它結合了早期的論壇和近期流行的社群媒體,有點像是把 Facebook 的社團這個功能放大到網站的層級(這也是我認為現在 Facebook 的最大的價值),不同的主題就集中到不同的站點上討論。在此同時,也可以直接跨站點直接分享嘟文,保留嘟文的來源,而不是用傳統複製貼上的轉貼的方式。 我覺得,這才是過濾和整理資訊比較好的方法,而不是像 Facebook 一樣全部攪在一起之後再想辦法用演算法去排序。就算需要,也早就有 RSS 這種可以收攏更多訊息來源的工具,也可以自由整理、排序所有訊息的順序。 人生沒有在全拿的 這種聯邦式的設計對使用者來說也造成難以避免的麻煩。 首先,使用者會需要在不同的站點跳轉。這在電腦上的瀏覽器沒什麼問題,只需要開一個新的分頁就解決,但在手機上就完全不是這一回事。手機上的瀏覽器使用體驗還是有點糟糕,跟 App 的差距還不小(但就技術上是能做到的),甚至有時候需要在 App 和瀏覽器之間跳來跳去,難受。也許統一收攏到 RSS Reader,當作是唯一入口,再用瀏覽器去打開連結,可能會是一個折衷的方案。 第二是如果要最大化觸及率的話,可能會需要在不同的站點上都註冊帳號,並且在上面 po 一樣的文章,這就讓跨站連通嘟文這個功能有點雞肋。雖然可以透過跨站轉嘟來某程度解決這個問題,但還是免不了需要到各個站上操作,這可能是 ActivityPub 目前的設計缺陷,這可能就要透過外部的第三方服務來管理了。 所以,我可能會考慮擴充之前我開發的 Liker.social 同步到 Instagram 的系統,變成是一個集中的發文管理平台,這樣我就可以在一個地方統一管理所有站點的文(可能包含以後的 Threads),就不用再手動一個站一個站發文或是轉嘟了。
陈仓颉
入驻第1年
碟中谍7
期待已久的碟中谍7终于上映,按照顶配 IMAX 观影。时长163分钟是系列最长,观影结束后最大的问题也出现在这 […]
Debug
入驻第1年
如何接手并维护一个项目
在工作中,接手负责管理别人开发或者前人开发的项目是每个开发人员的工作任务之一,那么,如何快速并且高效的消化接手过来的项目呢,本文主要讲解一些方法与实践技巧,希望可以帮助你快速了解你接手的项目。 系统文档 若是有最开始的包括后续优化的相关技术文档或者系统文档,对于接手过来的项目无疑是最有助于开发人员的方式。但是大家会发现往往接手过来的项目是没有这一类的文档的,交接过来的系统若是对开发有极高追求的,一般都会有文档,并且 README.md 中会有项目介绍包括相关文档,但是…… 往往我们拿到手的系统是纯代码,README.md 可能都没有这个文件,这种往往是最痛苦的,不过也是最锻炼梳理系统这项技能的。 那么我们就需要从下面这几个点来慢慢消化系统。 系统权限 交接过来的系统,一定要开好对应的权限,这对你全面了解系统以及后续维护系统有着至关重要的的作用,若没有权限,当系统出现问题时,领导找到你问问题原因,而你却在向领导申请权限,世纪名场面。 以下是常见的系统权限: Gitlab 仓库权限; Deploy 部署系统权限; Log 日志系统权限; Data 数据库管理系统权限; Alert 系统报警配置权限; Crond 任务调度器权限; Middleware 根据不同系统的中间件权限,包括不限于 Notify、RocketMQ、Redis 等; Auth 依赖系统授权信息权限; Test 测试平台的权限; API API 调试平台的权限; Sys 系统相关注册管理权限; 接手项目,开启权限是第一步也是必须要做的事情。 配置文件 通过配置文件可以看到一个系统的基本信息,比如说: 系统环境配置信息、注册信息、协议相关信息; 系统使用数据库配置信息; 系统使用 Redis 等中间件配置信息; 业务上使用的一些值定义; 库表设计 一般数据库表设计会存放在 dao 模块或者目录下,基本上是一表一文件定义,可以看到表定义的字段,并且可以看到对该表的一些“增删查改”动作。 若是底层系统设计,本身系统就是只提供给外部服务使用的,那么从数据库库表设计基本上就可以反推业务逻辑的设计,删除、更新、新增都是基本的业务逻辑动作,查询或者组合成事务的业务相对来说比较复杂,不过根据业务代码看着理解的话也比较简单一些。 缓存设计 缓存一般有两种,分别是: 被动缓存:一般是用于高并发场景,用于缓解下游中间件或者接口的瞬时压力; 主动缓存:这种是相对高级的缓存策略,用于分布式数据一致数据的返回; 分析刚接手的系统,从 cacheKey 就可以了解业务系统中为什么这样设计的: 1 product.info.pid.XXXX 上面这个例子可以看到记录的是一个产品 pid 为 XXXX 的缓存信息。 协议文件 若是接手过来的系统按照语义命名及划分路由的话,则通过 API 接口文档来看是一个很好的方式,因为通过 API 基本可以确定接手过来的服务有哪些业务,针对不同的业务又有哪些操作。 针对不同的语言、不同的协议,也有一些细微的差别: Java Dubbo 协议 一般 Java Dubbo 协议都是对外提供 API 模块的 pom 依赖的,声明都是使用接口来实现的: 1 2 3 4 5 6 7 8 9 // XXXX 业务模块 public interface XXXX { // 获取列表 Result<DataA> getXXXList(Context ctx, XXRequest req); // 获取列表 基于 uid Result<DataA> getXXXListByUid(Context ctx, XXRequest req); // 基于 uid 删除 XX 信息 Result<Boolean> delXXInfoByUid(Context ctx, XXRequest req); } Go Thrift 协议 Go Thrift 是使用 IDL 语言定义的协议,我们会基于 IDL 声明的接口,定义好接口出入参生成的 SDK 文件,通过看 IDL 定义的接口,就可以了解到接手的项目提供了哪些功能了: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 struct XXOrderResponse { 1:i64 orderId, 2:string orderInfo; } struct XXOrderRequest { 1:i64 orderId (go.tag = "json:\"order_id\""), } // 接口定义 service OrderService { // XX 订单 XXOrderResponse XXOrderInfo(1:XXOrderRequest params) } Go HTTP 协议 目前公司使用居多的 HTTP 框架是 iris 还有一个自研的 migo 框架(基于 beego 框架开发),都有一个相似的特点,就是会把 router 单独定一个文件,即 router.go : 1 2 3 4 5 6 7 8 9 10 11 12 13 // Init _ func Init(app *iris.Application) { app.Use(middlewares.RecoveryMiddle) app.Use(middlewares.PromeMiddle) app.Use(middlewares.LoggerMiddle()) // 小心打日志的配置 app.Use(innermiddle.CrossOrigin) // 是否使用跨域 app.Use(middlewares.RateLimitMiddleWare) // 配置限流 app.PartyFunc("/product", cproduct.Register) return } 编程语言 从依赖方去挖掘系统,看系统依赖了哪些业务方,也可以看出系统依赖了哪些基础包,还可以看到依赖的包对应版本(有经验的人可以看出是否有 bug )。 Java Maven 目前 Java 主流的依赖方式就是使用 Maven POM 定义依赖并管理依赖: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent> <artifactId>product</artifactId> <groupId>cn.debuginn.blog</groupId> <version>1.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>product-server</artifactId> <dependencies> <dependency> <groupId>cn.debuginn.blog</groupId> <artifactId>product-api</artifactId> <version>${product-api-version}</version> </dependency> <!--单元测试--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> </dependency> </dependencies> </project> Go Module 目前 Go 语言也是大一统到 go mod 管理版本依赖了,由于 Go 是源码依赖,使用 go mod tidy 之后就可以通过点击依赖仓库来看源码了: 1 2 3 4 5 6 7 8 9 10 module github.com/debuginn/go-demo go 1.20 require ( github.com/dubbogo/gost v1.11.25 // indirect github.com/go-playground/validator/v10 v10.10.1 github.com/go-redis/redis/v8 v8.11.0 github.com/gobwas/ws v1.0.3 // indirect ) 流程图、泳道图 通过上述方式与方法,最后就可以根据业务代码,画出业务流程图及对应的泳道了,同时,也可以基于依赖关系,画出系统的架构图,梳理一个系统的最好方式就是有所沉淀,通过读代码把代码转化为文档的方式即可以对消化的系统有所输出,又可以提升自己的技术能力。 写在最后 最后,一个好的系统,是由系统设计文档、代码、注释和覆盖率尽可能全面的测试用例组成的,很多情况下大家由于不可抗拒的原因,最后只留下了运行的代码,这也是撰写本文的主要原因,希望对大家有所帮助,最后大家有什么好的方式和方法也可以在评论区分享出来,让我们一起变得更强。 关注微信公众号,第一时间获取最新内容,让我们一起变得更强!Debug客栈:订阅本站· 文章归档· 我的项目· 友情链接· 我的使用· 飞湾计划· 摄影展集· 我的主页
JN
入驻第1年
一些我對 Threads 的淺見
2023/07/06,Meta 的新平台 Threads 上線,我想你應該早就知道這件事情。我自己在幾個月前就聽說這個消息,並且持續在關注,因為消息指出這個代號為「Project 92」的新平台將會支援 ActivityPub,意即將會與 Mastodon 等社群平台相容。 首發當天我就下載並註冊帳號了,不意外地是讓我很失望。但 7/6 這天僅僅是 Threads 的公開測試,還不是正式發布,不能期望它已經是個成熟的平台,但還是請容許我用比較嚴苛的角度去審視,就當成是我對 Threads 正式發布時的期許。 尚不支援 ActivityPub 這應該是我最在意的事情。我對這個平台最大的期許就是能和 Mastodon 相容,讓我能夠使用在其他站點上的帳號就能與 Threads 上的內容互動,而不是被受限必須使用 Threads 的帳號和 App。 在 Meta 推出 Threads 當天發布的文章,主題是介紹 Threads 這個平台。內容不斷強調 Threads 的一個重要目標正是支援開放的協定 ActivityPub。 但是,目前 Threads 只能用官方的 App 存取(以及可以使用網頁做簡單的讀取),還沒開放 API。所以,在 Threads 接上 ActivityPub 的網路以前,它無疑是被關在 App 的一座孤島,所有和外界的溝通只能透過 App 這種猶如空投的方式進行。 為打倒對手而生的產物 Threads 推出的的時機也是奇妙,剛好是 Twitter 發布「每日免費用戶只能瀏覽 1000 推文」的數日後,再加上兩個平台的介面及使用方式極其相似,Threads 在這個時間點推出很難說不是早就預謀針對 Twitter。 但是,Threads 真的有充裕的時間開發,準備好了才被推出嗎?就我一個非專業程式開發人員的觀察,我想答案是否定的,我看到的是滿滿因為時程緊迫下的妥協。 不只是前面提到尚未支援 ActivityPub 以及沒有網頁介面。而我的猜想是:整個 Threads 的系統可以說是 Instagram 的一個文字版外掛。為什麼我這麼說呢? 除了從 Instagram 和 Threads 的帳號 ID 會同步、刪除帳號時會同時刪除兩個 App 上的帳號,可以推測出其實是共用一個帳號系統以外,根據 逆向工程得出的 API,Threads 背後的 API 其實也是打到 Instagram。所以可以說背後其實是同一個系統,只是以不同 App 來存取做出品牌上的區隔。 但講個題外話,即便是共用同一個帳號系統,要讓用戶能夠取消註冊其中一個平台,在技術上是完全可行的事情,Meta 也承諾未來將會做出這個修改,整個專案趕鴨子上架的情況可見一斑。 糟糕的演算法 我能明白整個平台還在公開測試階段,演算法還處在非常簡陋的階段,還有很大的調整空間。但根據我短暫的使用經驗,Threads 的首頁會出現不少自己沒有追蹤的帳號,有些是朋友的朋友,有些是 KOL。 我很明確知道這不是我想要的,我需要的就是「按照發布時間,顯示我有追蹤的帳號的 po 文」。這麼簡單的演算法,Meta 不可能沒有能力實現,我翻遍了所有設定也沒有選項可以調整首頁的排序模式,表示 Threads 有可能在未來也延續這個政策,利用演算法來推送他們希望推送給用戶的內容。 這其實也就點出 ActivityPub 的重要性,如果 Threads 支援的話,我就可以在別的站台追蹤我想追蹤的人們,在別的站台做排序,我就可以選擇不要被迫吞下 Threads 的糟糕演算法。 我不信任 Meta 想想 Instagram 當初剛被 Facebook 收購的時候也還是個小清新,後來漸漸地首頁才不按照時間排序、開始加入廣告跟陌生人的貼文,最後還硬推 Reels。原本不錯的使用體驗一直被 Meta 破壞,但身為使用者因為必須到 Instagram 才能看到自己想看的東西,所以都必須乖乖地吞下去。 Instagram 之所以會有這樣的變化追根究底還是因為商業利益考量,類似的事情也很可能在 Threads 再發生一次,但假設 Threads 真的支援 ActivityPub,使用者就有官方站台以外的選擇,並且還是可以看到想看的東西。現在 Meta 講得很好聽,想加入這個自由的去中心化網路,但商業模式是什麼?這不是在拿石頭砸自己的腳嗎?所以我認為,就算 Threads 在未來支援 ActivityPub 了,Meta 還是能想出新的方法把用戶不得不選擇官方 App,以維持他們以廣告為主的商業模式。 做個總結,支援 ActivityPub 前的 Threads 其實就是另外一個 Twitter 而已。如果支援了,那將會有一段天下太平的日子,Threads 和其他所有支援 ActivityPub 的平台的使用者都可以直接互動,不必到對方的站台註冊帳號。但隨著 Meta 需要在這個項目轉虧為盈,可能就有新的方法把還留在 Threads 上的使用者當韭菜割。 所以,Threads 這個平台我自己雖然已經註冊了帳號,但我不會想住在上面。假設支援 ActivityPub 了之後,那就更沒有理由住在上面,因為我可以直接從別的站台追蹤還留在那上面的朋友。只怕的是在未來 Meta 出了什麼噁心的招數,不只把 Threads 的使用者當韭菜割,還可能逼在其他站台的使用者不得不加入 Threads,那就很糟糕了。
JN
入驻第1年
我的聲音旅程 || 構成自己的 42 張專輯
看見夥伴分享了影響自己最深的 42 張專輯,正好才剛寫完 如何提升自己的音樂品味?,我也搭上這個順風車來分享一下~ 首先,身為一個在 mp3 時代長大的台灣人,把整張專輯一聽再聽的經驗還是比較少的。所以,我決定以專輯內的單曲或樂團為單位來選擇。 說實話,42 張還是頗尷尬的數字,既不能只挑出那些在自己聲音之旅中的重要節點,也不能任性地把所有值得不斷循環的作品都列入這張圖中。最後,終究還是必須忍痛捨棄掉一些自己真的很喜歡的作品;也當然,有很多漏網之魚是沒有被列入的。 我的音樂品味深受日本影響。自己珍藏的曲庫中,有很大一部分是從日本的演出資訊中挖出來的。如果喜歡日本音樂,卻還沒深入這片叢林的話,我相信你一定能從這份清單獲得一些寶藏。 為了使結果更多元,每個樂團我只挑選出一張專輯為代表。同時,一張專輯代表了一個樂團,也可能代表了其中的一首單曲。 排列也是有邏輯的:最上面 10 張專輯代表了我從有意識聽音樂以來,這個歷程中的重要節點;中間 12 張則是最有代表性的樂團;最後 20 張則是剩下之中最喜歡的作品。 先聚焦在代表我的聲音旅程的前 10 張,每一張都是前一張的延伸或繼承,而且有各階段的指標意義: CNBLUE - RE:BLUE > K-Pop 流行樂團 Ikimono-Gakari - 桜咲く街物語 > J-Pop Scandal - HELLO WORLD > 日本流行樂團 都市零件派對 - 大城•小事 > 台灣樂團 JOKER - 奔跑 > 日系、結構精緻的編曲 茄子蛋 - 卡通人物 > 詼諧、頗具個性的吉他 Rick Rack - 今を生きぬく乙女たち > 類 Funk 吉他 + Disco 鼓節奏 Lucky Tapes - CIGARETTE & ALCOHOL > 性感的 Bass Vantage - J-Funk City : Vantage’s Edits Collection > Future Funk、EDM POP ART TOWN - SWEET! SWEET? SWEET! > 綜合前三張的特點 聽到 Rick Rack - 今を生きぬく乙女たち 的時刻是一個比較大的轉捩點。在那之後,我的音樂品味不再是到處摸索的階段,而是幾乎專注於特定的幾種曲風,也就是後面的那四張。 後面的 32 張,則大部分出自於那個轉捩點之後,也就是說,這 32 張幾乎都能對應到這四張的其中一張。基本上,我也是以那幾張的風格在分類我的曲庫。在此附上完整的清單: CNBLUE - RE:BLUE Ikimono-Gakari - 桜咲く街物語 Scandal - HELLO WORLD 都市零件派對 - 大城•小事 JOKER - 奔跑 茄子蛋 - 卡通人物 Rick Rack - 今を生きぬく乙女たち Lucky Tapes - CIGARETTE & ALCOHOL Vantage - J-Funk City : Vantage’s Edits Collection POP ART TOWN - SWEET! SWEET? SWEET! Polkadot Stingray - Honenuki E.P. Wienners - BURST POP ISLAND GOHOBI - CAN’T GIVE YOU UP ラパンテット - 小籠包 Andend boom - JUMP Anoatari - Anoatari (~2018) SHE IS SUMMER - WATER Dareharu - Karma 渣泥 - 半心 cinnamons - summertime Oresama - CONTINEW WORLD (DISC1) Necry Talkie - One! Hump Back - 夜になったら Yorushika - 夏草が邪魔をする Friends - Petit Town ZUTOMAYO - 潜潜話 House Rulez - Mojito O.O.O - GARDEN Anna - I’m not alone hitori no sekai 川嶋志乃舞 - ファンタスティック七変化 ANARCHY STONE - KNOCK OUT!!! 問題總部 - Lost Jack Thammarat - Still On The Way 倒抽一口氣 - 倒抽一口氣 プルモライト - リインカーネイション Luck Life - Tadashii Boku No Tsukurikata Tomo Fujita - Put On Your Funk Face Blu-Swing - BLU-SWING 10th ANNIVERSARY BEST MY FIRST STORY - ANTITHESE JABBERLOOP - CHECK THIS OUT!! 放客兄弟 - 放客兄弟 體熊專科 - Topic 2: 關係 Relationship 這次整理 42 張專輯的過程還是比較倉促、不嚴謹的,而且,這充其量只能說是我的品味養成脈絡的目錄而已。只用前 10 張專輯還是不能清楚地解釋為什麼今天我的品味是這個樣子,這整個過程是什麼?每一張專輯彼此的關係又是什麼? 如果能夠把專輯排列,並且用線將他們連結,完成一個樹狀脈絡圖,感覺是一件很有趣的事情! 最後附上用來製作這張圖的網頁: https://www.neverendingchartrendering.org/
JN
入驻第1年
如何提升自己的音樂品味?
前陣子收到一些回饋,多是來自不曾學習過樂器的小夥伴,都在回饋中提到自己不懂樂理或不知道音樂怎麼分類之類的。其實我認為每個人都能以自己的見解養成自己的音樂品味,非得要遵照大家公認的那一套。一個原因是我自己的樂理程度不高;另一個原因是我認為音樂是很直觀的「感受」,而樂理只是從音高的組成的角度提供每個人對這些感受同樣的命名,使得這些感受能夠被重現和傳授。不過既然有小夥伴覺得自己有點迷茫,我就來獻個醜,分享一下我自己的音樂品味是怎麼養成的,以及我認為可以用什麼方法提升自己的音樂品味。 免責聲明 老實說我其實不太能確定,我自己在這幾年音樂品味的變化是變好還是變差?在成為一個編曲結構宅的同時,我也失去了欣賞很多其他音樂的能力。歌曲本身也是一種複合式的藝術,故事、意境、情緒、其他元素,都能是歌曲除了音樂外的一大重點。以下僅僅是來自一個理工腦的意見,僅供參考。 聆聽設備 首先是聆聽的設備,我認為這是能從音樂中獲得多少資訊的先決條件。一個好的聆聽設備可以保留更多的「細節」,例如樂器的配置、混音的巧思,這些細節有時候是跟關鍵的。農村武裝青年的主唱也說過「用手機喇叭在聴音樂是在浪費音樂人的心血」這種話,畢竟如果連聽都沒有辦法聽得清楚,還談何品味? 我認為一個合格的聆聽設備至少要能夠把幾個比較大的聲部分離開來,也就是它們不應該全部都混在一起。如果你去注意各個樂器的位置的話,一個簡化的版本也許會類似這張圖: 更好的設備越有機會把每個聲部分離的越清晰,或是上下左右前後的寬度會寬,也就是所謂的音場大小。至於該多分離、音場該多大就是個人的喜好,但絕對不會是像大創的 $39 耳機一樣,像一鍋粥全部糊在一起,這就是一分貨一分錢。 我認為大部分大品牌的最入門型號的耳道式耳機都能勉強符合以上的標準,常見的 Airpods 或是 Earpods 也是算是不差的耳機。如果預算很有限的話我會推薦對岸品牌 KZ 的 ZSN(非 Pro),大約 $600 NTD 能入手了;耳罩式喇叭可能就需要準備 $2000 ~ 3000 以上;至於喇叭我就完全不是我熟悉的領域了。 舊歌新聽 現代音樂的混音幾乎都使用電腦完成,不存在硬體混音器的音軌數的限制,40、50 軌幾乎就是家常便飯,除了同樣的聲部可能疊了很多層來加強厚度以外,在大聲部的縫隙之間存在很多很不起眼、平常不會注意到,但其實默默貢獻了很多的樂器。我覺得嘗試去做逆向工程,找到那些音樂製作時的小巧思是很有趣的事情,也是我用來更深入欣賞一首歌曲的方式。 分析 另一個很有效的方法,就是問自己「為什麼喜歡一首歌?」、「為什麼不喜歡某種特定類型的音樂?」、「這首歌跟那首歌哪裡不一樣?」。也許你能夠明確地知道答案,但大多數的時候是模糊的,甚至是一點頭緒都沒有。我覺得「明明喜歡卻不知道為什麼」對我來說是一件很矛盾的事情,也許我沒辦法馬上找到答案,但每次解開疑惑的過程,都是我主動地在嘗試拓展我的品味的時候。 至於要從哪些維度去分析因人而異,沒有標準的方式,結構、配器、和聲、節奏、混音、詞曲咬合,還有很多其他很多很多能切入的角度,甚至每個人也會有自己獨特的角度。而從那一大堆維度挑出了哪一些出來重點發展,就是形成品味很關鍵的一件事情。 製作 我認為要快速提升品味的方式還是去了解如何製作,甚至是自己嘗試。無論是學樂器、作曲、編曲、混音都好,都一定需要學習那個領域的工具,例如:樂理之於樂器、濾波器之於混音。多學習了一個工具就是多了一個分析的角度,意味著存在再拓展品味的可能。 一個具體的例子就是 Wiwi 分析自己的作品 。如果不是曾經參與音樂製作的人,應該都能從這支影片得到不少新知識。 耐心 音樂品味的養成不是一朝一夕的事情。以我自己為例,我在擁有人生第一支像樣的耳機和接觸非主流音樂後的幾乎三年後,才開始找到自己真正喜歡聽的音樂類型。雖然早就接觸吉他好幾年,但在那之前的我就是字面上的「都聽」,覺得什麼好像都不錯,但又說不太出來自己為什麼喜歡的那種。至於這中間的過程發生了什麼事情,就在之後再和大家分享啦~
Debug
入驻第1年
我的项目
🤠 Hi,我是 Meng小羽 下面是我目前所使用到的技术栈及工具: Projects 项目名称 语言 项目介绍 Star golang-developer-roadmap-cn 在 2019 成为一名 Go 开发者的路线图,为学习 Go 的人而准备 douban-movies 如何将豆瓣观影记录实时同步至博客中 photo 个人摄影展集 hugo-theme-skills Hugo 主题,用于构建 Skills & Tools 展示站点 leetcode 📝 算法 / SQL / Shell 题解 OpenHosts OpenHosts skills AI Skill Tools 关注微信公众号,第一时间获取最新内容,让我们一起变得更强!Debug客栈:订阅本站· 文章归档· 我的项目· 友情链接· 我的使用· 飞湾计划· 摄影展集· 我的主页
Debug
入驻第1年
全站静态化升级完毕
经历了三个月的整体站点迁移,数据的修复,网站的搭建,目前全站代码已经完成 github 代码托管部署,主站点重新调整设计,以后就不需要关心网站的动态部署问题了,代码托管的部署方式更有利于版本的迭代与维护,同时博客站点使用的是 markdown 文章,不必使用后台,也避免了被暴力破解的风险,接下来持续输出,更加注重文章的质量与水平,多输入多输出。 Debug客栈-主页 https://debuginn.com Debug客栈-博客 https://blog.debuginn.com Debug客栈-笔记 https://notes.debuginn.com Debug客栈-摄影 https://photo.debuginn.com 感谢支持,欢迎你持续访问与评论~ 关注微信公众号,第一时间获取最新内容,让我们一起变得更强!Debug客栈:订阅本站· 文章归档· 我的项目· 友情链接· 我的使用· 飞湾计划· 摄影展集· 我的主页
JN
入驻第1年
聲音旅程 #1:K-pop 二代團
這是我的「BlogBlog 同樂會 - 2026 年 6 月」的投稿文章。本月主題是「音樂與記憶」,由柚子主持。如果你有自己的部落格,歡迎一起來參加! 之所以挑這篇舊文投稿,是覺得「聲音旅程」這件事情實在串起了我很多記憶哇!我覺得是很有趣的事情,也推薦大家做做看! 聲音旅程 如果要說影響我近五年的生活最大的一個事件的話,那應該是參加 淺動 吧!淺動是幫助高中生進行音樂創作的營隊。當初是一位學姊邀請我成為學員的,如果沒有認識那位學姊和參加淺動的話,我可能就不會認識訂閱九弄絕大部分小夥伴 XD 進入正題,「聲音旅程」是淺動的課程之一。在這堂課程中小隊內的每一位成員分享自己聽音樂的歷程,並且畫成一張關係圖,藉此來了解彼此的音樂品味如何。我覺得這件事情很棒,因為每個人的音樂品味都不停地在變化,但很少有機會去梳理其中的脈絡。此外,跟不同背景的人交流的時候也會有「原來有人是用這種方式在聽歌」的時刻。 我想再一次細細地回顧我的音樂品味是怎麼發展越走越歪的,也順便和你分(ㄊㄨㄟ)享(ㄎㄥ)那些我在每個時期影響我非常多的音樂作品 ٩(•̤̀ᵕ•̤́๑) 雖然淺動鼓勵從小時候一開始接觸到音樂開始(跟著爸媽一起聽音樂之類的),但我還是比較喜歡從我第一次拿到 MP3 Player、我可以開始有一點權利我要選擇聽什麼音樂的時候開始。 K-pop 那時候正好是 K-pop 開始席捲全球的年代,我的 MP3 裡面存的幾乎都是韓國歌。在那個時期我最愛的是 CNBLUE,我後來會想要學吉他也是因為他們XD 不過我在那個時候的音樂品味實在不可考了,或者應該說根本沒什麼品味,基本上還是電視上播什麼就聽什麼,頂多只能確定自己不太喜歡嘻哈音樂,所以我這邊就只能用薄弱的記憶加上現在的品味去挑一些歌出來: CNBLUE CNBLUE -「Wake Up」 我從來沒想過這種規模的(偶像)演唱會還是可以做到如此的互動張力,原本三分半鐘的歌演了將近 12 分鐘(!) CNBLUE -「Coffee shop / I’m sorry」 難得在打歌節目上能夠不假彈的演出,兩首歌都有很棒的吉他 riff! Davichi Davichi -「時間啊,停止吧」 Davichi - 「8282」 少數在台上不跳舞的團體。那時候這種主歌像抒情歌、副歌又變成舞曲的歌還是讓我蠻驚喜的 題外話:我那時候覺得左邊的姜敏京很正,後來整型整到完全不一樣了 可愛可愛的女團歌 少女時代 -「Kissing You」 Afterschool BLUE -「WONDER BOY」 Apink -「I don’t Know」 這幾首都是可愛可愛的女團歌,共同點是副歌的和弦進行沒那麼「乖」,或多或少用了一些不在非順階和弦,Vocal 的旋律也都很 catchy 不小心就要推太多首了,因為我對 2010 ~ 2012 這段時間活躍的團超級、超級、超級熟,但大部分也僅止於出現在打歌節目上的幾首主打歌,如果你有一些珍藏的 B-Sides 的話,拜託一定要跟我分享 Orz
JN
入驻第1年
Discord 變爛的起點
Fosscord 收到來自 Discord 的律師信,要求他們立即停止所有開發以及刪除所有的公開資訊。以下擷取自 Fosscord 在 Discord 上的公告: On the first of March, the Fosscord maintainers received an email from Morrison Rothman LLP ( Discord’s Lawyers ) notifying us about how they believe Fosscord to be an infringement of their intellectual property. As such, they requested that we immediately stop development and remove or take down all available code, services and social media. This includes our website, our Github repositories, etc. 先稍微說明一下 Fosscord 是什麼: Fosscord 是鄉民自製版的 Discord,目前還在開發中,目的是在讓所有人都可以自己建立自己的 Server 的同時,提供零差異的相容性。 而 Fosscord 和 Discord 是兩個「完全獨立」的服務,也就是說,Fosscord 完全無法直接存取到 Discord 伺服器上的資訊。 也因此,Fosscord 的開發者們都認為他們沒有違反任何法律,而最後他們決定移除所有和 Discord 有關的商標、字樣,其中包含取一個新名字。 這件事情所透露出的訊息是:Discord 即將開始成為傲慢的大公司,就像是 Meta 或是 Google 一樣,只要他們成功把所有的競爭對手壓得死死的,讓用戶別無選擇,接下來就可以對用戶開刀,來一波養套殺。 當然,如果要比爛的話 Discord 還是比不過 Meta,至少在 API 的支援、以及對開發者友善的使用環境絕對能算是前段班,而且 Discord 很大一部分收入來自 Nitro 的訂閱費用,也算是暫時可以「比較」安心使用的理由之一。 但如果長遠來看的話,Discord 也不是一個好地方,還是要找一個更自由更開放的平台才行,譬如 數位難民 again 說的支援 Matrix 的平台們。
JN
入驻第1年
Meta 的新平台 Code Name:P92
這新的App將以聯邦式網路協定ActivityPub為基礎 ──挑戰推特,Meta籌畫去中心的社群服務 上禮拜才噴完 Meta 一波,這禮拜就來一個好消息(吧?) 來自 2026 的劇透:不是好消息,那就是 Threads.net 看來社群平台在接下來這一兩年會開始大風吹了,Elon Musk 把一堆原本的用戶逼到 Mastodon 上,Meta 也想要趁機會搶走其中一部分的用戶,現在比較多人使用的 Facebook、Instagram、Twitter 這些社群平台的末日指日可待。 但有一個壞消息,如果要從 Instagram 搬家到這個新平台的話,除了最基本的個人資訊以外,似乎是沒辦法一起帶過去的,That sucks。 再囉嗦解釋一下 ActivityPub 到底是什麼,支援 ActivityPub 到底有什麼好處? 簡單來說,ActivityPub 可以讓不同的社群平台之間彼此交換資訊,用戶就不必在被綁架在一個爛平台上面,每個人也可以選擇要待在什麼平台上,而且依然可以獲得在其他平台上的朋友的資訊。 現在的 Instagram 或是 Twitter 都是中心化的平台,也就是說,所有的伺服器以及資料都被掌握在一個組織手中,如果你需要使用這個平台,唯一的方法就是連到該平台的伺服器。 這會造成什麼問題呢?最大的問題就是,那些平台的擁有者就彷彿是神一般的存在,今天要演算法要修改成什麼樣子、哪些內容會被 ban、廣告出現的數量、你的個資要怎麼運用,所有的一切都是平台擁有方說了算。 拿我自己的情境舉例:因為 Facebook 並沒有提供使用官方網站或是 App 以外的方式獲得粉絲頁貼文資訊,我就被迫要用更繁瑣的操作、同時忍受官方 App 的糟糕使用體驗,才能看到某個只 po 在 Facebook 上的表演資訊。 想像一個美好的世界,你媽還是想待在 Facebook 上,你的朋友們都在用 Instagram,你追的 VTuber 都只在 Twitter 上發文,還有我這個愛標新立異個朋友只在 Mastodon 上。 但你只要一個帳號,打開一個 App 就能看到所有的貼文,這就是 ActivityPub 能做到的事情,前提是所有的平台都支援。 還是那句老話,歡迎來追蹤 liker.social 上的我 g0v.social 上的我,因為 ActivityPub 的強大,你可以在從任何一個 Mastodon 的平台追蹤我,甚至在不就的將來你也可以從 Tumblr、Flickr、還有 Meta 的新平台追蹤我1。 2026 更:才怪,Threads 對 ActivityPub 的支援還是破破爛爛的。 ↩︎
JN
入驻第1年
AI 會取代人類嗎?
全世界最大的程式問答網站 Stack Overflow 禁止使用 ChatGPT 來產生回答,他們給出的是一個非常工程的理由。 如果全部的資料都是 AI 產生的,那以後就沒有新的資料來訓練新的 AI,整個 AI 的發展就會陷入死胡同。 我倒是想用另一個角度來看這個問題:即使現在製造業已經大規模地使用機器來自動生產,純手工的產品還是非常有價值,甚至大幅超越那些機器量產的產品。也就是說,從生產的角度來看,就算機器可以做得比人類更好更快,人類手工生產還是無法被取代。 如果你常用 Google 之類的網站搜尋引擎,你應該可以常常看到你在打了一段字之後,推薦的關鍵字會有 PTT、Dcard 等等的公開論壇。 同樣的事情不只出現在臺灣,Reddit 或是上面提到的 Stack Overflow 也是很常出現的關鍵字推薦。非常有趣的一件事情是:隨著 AI 的越來越強大,Reddit 在 Google 被搜尋的次數不但沒有減少,甚至絲毫沒有走下坡的趨勢。 我認為,由人類產生的內容會越來越珍貴。 舉個例子:在網購平台底下那些由真實賣家提供的評價,因為你和我都是人類,我們想要知道其他和我們一樣是人類所產生的想法,這是科技無法做到的事情。 對於抽菸的人,利用科學和超大樣本的研究文獻證明了吸菸會導致比較高的罹癌機率,可能還不如一個親人死於肺癌來得有說服力。 至於現在大部分人類產生的內容,都被關在一個一個的平台裡面,無論是 Facebook、Twitter、或甚至是私人群組都一樣,他們都沒辦法直接從 Google 或 ChatGPT 找到,只有少部分能從 PTT 這種公開論壇流出來。 而那些內容就是那些平台賴以維生的資產,也是為什麼 Google 現在越來越難用的原因。
JN
入驻第1年
數位難民 again
我不想看到的事情又出現了。 分拆多年終重新整合 Facebook 宣佈 Messenger 回歸主程式 雖然從很久以前就說想要把好幾個通訊軟體都刪掉,但看看我手上仍然在用的那堆,分別是: Discord LINE Messenger Instagram Telegram 實在是有夠痛苦。除了同樣出自 Meta 的 Messenger 和 Instagram 以外,可以說是毫無相容性可言。也就是說,我沒有任何方法可以傳送跨平台的訊息。 也許你會覺得我想的是什麼天方夜譚,但如果我說今天這種情況就像是三大電信商彼此不互通、或是 Yahoo Mail 沒辦法寄信給 Gmail,這麼一類比的話,我的夢想應該不過分吧? 甚至 Yahoo! 即時通曾經還可以跟 MSN 還有 Facebook 的使用者互相傳訊息。 其實這件事情也不是沒有人在做,matrix 就是通訊軟體的開放標準之一。但可想而知,這種無利可圖的計畫,自然是不會有企業協力推廣,因為那根本就是在拿石頭砸自己的腳。沒有企業支持意味著沒有資源,也沒有能見度,也就只能靠著一小群鄉民自力更生。 在大約兩年前,我曾經自己架起 Matrix 的伺服器測試過 ,在當時的官方 App 的使用體驗還是很糟糕,我猜在兩年後的今天,即使有進展也是很難令人滿意。 Messenger 一直是我大部分的對外聯絡管道,原因除了幾乎所有身邊的人都會用以外,很簡單的決定性因素就是它是獨立的 App,不像 LINE 、Instagram 綁了一大堆跟「通訊」無關的功能。在 Messenger 也要收掉之後,我實在不曉得何去何從,也是只能請大家先加我 Discord 吧。 不過老實說,對於 Discord 我還是有點疑慮,所以我一直都說我我在 Discord 「暫時避難」。疑慮的理由是因為 Discord 依然是一家以營利為目的的公司,並且沒有開放原始碼,難逃哪天上演養套殺的環節,就算有豐富的 API 可以使用,但如果有一天要搬家的話應該也還不是一件簡單的事情。 但別誤會,我十分願意付費使用服務(畢竟免費的最貴),只是如果是像 Google 那種先把你綁架再來割韭菜的方式,我想任誰都會覺得倒彈。 回頭再看看 Email,存在了好幾十年還是活得好好的,因為它是公開自由的通訊標準。 延伸閱讀:Protocols, Not Platforms: A Technological Approach to Free Speech
JN
入驻第1年
Electro Swing:靠!這我早就聽過了
連假的時候看到這支 YouTube 影片: 「阿靠,這不就是 HoloCure 的 BGM 嗎」 後來我稍微在 YouTube 上找了一下 Electro Swing 的資訊,發現這個曲風可以是大量取樣(像是 Future Funk),也可以是原創,但無論如何,它們幾乎都用了一樣的節奏和極為類似的和弦進行,變化跟其他的曲風比起來可以說是幾乎沒有。 舞蹈對於這個曲風來說似乎佔了很大的份量,是實實在在的 EDM,而且看起來有著相對低的門檻(和 Ska 有類似的性質),我能想像如果在 The Bar 能有這樣的場次的話應該會很讚。 (其實看起來蠻療癒的) 而見識短淺的我到此時我才恍然大悟,原來有另外一條線能把好幾首歌串在一起: 最後這首 BAAM 在前奏的舞蹈很明顯就是 Electro Swing 的風格,以前從來都不知道有這件事情,同時也驚嘆韓國人能用精緻的工藝去把俗濫的東西做到另一個境界。
JN
入驻第1年
Code as Entertainment
我之所以會想要學用 Code 寫音樂,除了很大程度受到 Sam Aaron 的啟蒙外,上面這個頻道也佔了一部分因素。 對我來說,看這個頻道的影片是一種娛樂,我並不是抱著學習機器學習的心情來看的。我想這支影片應該不需要太多的技術背景就能看懂在幹嘛,甚至是能夠面向一般大眾的。 他省略了很多 Coding 的細節,但又保留了很多 Debug 的痛苦,而且專注在 AI 天生比較吸睛的結果上。得益於他的剪輯風格,就算是 20 分鐘以上的長片,也不覺得冗長。 於是我一直在思考,Code 除了可以拿來做很宅的事情以外,有什麼方法是能帶給一般大眾娛樂。 身為一個沒很會寫扣的小菜雞,要寫出什麼網頁或是 App 帶給大眾價值不是簡單的事情,畢竟有多少公司是大把大把地燒錢在做這件事情,跟他們對幹我沒有什麼優勢; 至於在互動設計圈內稍有風氣的 p5.js 或是 Processing(寫 Code 產生視覺藝術的工具),我也佔不到什麼優勢,畢竟我對視覺的 sense 是有待加強。放眼望去,似乎只有音樂這個方向有一點點希望。 前幾天才看到 這位日本大大 用 Sonic Pi 寫了不少很不錯的作品,我認為他已經在這個領域做到頂尖的水準,但似乎沒有多少人注意到他。 在得到很多學習素材的同時,也讓我的信心下降了不少。
JN
入驻第1年
Holocure:超對我胃口的同人遊戲
想不到8,在這裡也能看到油油的東C 不過zq我沒有在看 VTuber 啦,但我要很認真推這個遊戲! 如果你對遊戲稍微有關注的話,你可能會知道去年在 Steam 上從 Pre-Release 就很夯的 Vampire Survivors,這個遊戲就是模仿 Vampire Survivors, 以 Hololive 為主題的同人遊戲。 雖然是同人遊戲,但我覺得品質一點都不馬虎。不光是每個角色的技能組都對應到一個 VTuber 的人設(雖然我幾乎不認識),畫面和 Vampire Survivors 一樣是 Pixel Art 但看起來和諧許多。重點是,這個遊戲的音樂的製作水準非常高,用 8-bit 風格把 Hololive 的歌重新編曲,我完全可以為了聽音樂打開這個遊戲! OST 傳送門 除此之外,這個遊戲在最近的大更新之後有將近 30 個角色、6 個關卡、15 種武器(+ 組合武器),一個小品遊戲還是可以輕鬆殺個 50 小時以上的時間。 [官網傳送門]
JN
入驻第1年
失敗的筆記法
停擺的防彈筆記 去年大約九月讀到《防彈筆記法》這本書之後,我就開始實行到我的生活當中,甚至自創了 一個方法,規定自己每天要完成至少三件事情。 一直到過年期間,我給自己發那個了一個大長假,自己想做什麼事情就去做。也是從那個時候開始,我的那些筆記也很少被打開,這也是最近幾期電子報沒有幸福小事的原因。 我不把這件事情當成是壞事,如同前陣子結束的那段感情。以一個宏觀的角度來看,我並沒有因為不這麼做就生活空洞,甚至還覺得對生活的掌握度提高了,不再常常覺得時間不是自己的。 如果要客觀的事蹟來佐證的話,我不那麼做以後,也沒有出現電子報難產的情況。因此我覺得,或許這是個機會讓我自己去想想接下來該怎麼做。 出了什麼問題? 《防彈筆記法》這套筆記法有很大的瑕疵嗎?我不這麼認為,至少對於我在工作用的筆記效果很好。 我目前的想法是:這只是物極必反而已。我用了一個不是那麼好的方法去執行,規定自己每天要完成三樣事情,其實是一個不小的壓力,我的注意力也就因此從「找到想做的事情」變成「找到好幾件事情來填滿那些空格」。 而長期來看,很多我本來想完成的事情也一直被擱著(看看被我剪好的布到現在還是躺在旁邊)。既然這樣,與其讓自己過得那麼有壓力,不如就讓自己舒服一點,在不只是被動接受演算法提供的資訊的原則底下,去做自己真正享受的事情。 「每天」= 失敗 除了這次防彈筆記的失敗外,一年多前的 100 天挑戰、還有失敗無數次的流水帳也是類似的結果。統整這幾次的經驗,似乎只要規定自己「每天」要做到的事情,最後都會以失敗收場,並且是很大的反彈那種。反觀電子報,從開始到這期也持續了將近半年,至今沒有遇到任何嚴重的阻力。 其實關於「每天」的挑戰也不全都失敗——統測前每天讀書、替代役期間每天刷 LeetCode、甚至是 100 天挑戰前半段取得證書的 27 天,在我的定義這些都無庸置疑是成功。而這幾個挑戰都有一個共通點:他們都有明確的目標以及事先規劃好的步驟,只要按部就班執行,就能得到明確的回饋。 失敗的共同點 看看那些失敗的挑戰,要不是每天都要想接下來要做什麼,就是缺乏一個明確的目標。 其實稍微想想就會覺得很合理,前者就如我上面說的,注意力會被拉走,變成每天都在「想辦法找到下一步」,結果就是找到的事情總是一些輕鬆但無關緊要的事情;後者則是因為缺乏對目標的想像(白日夢),沒有期待就沒有多巴胺,也就不會有動力。 越追越遠 「過好自己的生活才有機會進入一段不錯的感情」 「得獎的選手靠得不是苦練而是享受追求進步的過程」 「賺大錢的 YouTuber 出發點不是賺大錢」 「心情三能上台大音樂節只是專注做好作品(?)」 我不太曉得要怎麼描述幾句話微妙的共通點,「機會是給準備好的人」或是「無心插柳柳成蔭」好像都只是擦邊球,我就暫且統整成「越用力追求一個目標就會離那個目標越遠」好了。 這句話似乎也能套用到我執行防彈筆記法這件事情,或應該退一步說,追求生活。當我設法去達成這個目標,用了逼迫自己每天都有產出這種極端的手法,結果就是必須是大反彈,將近一個月都沒有動力打開筆記軟體來紀錄生活。 至於下一步該怎麼做?老實說我自己也不太曉得,但既然下班的時間那麼珍貴,作些自己真正享受的事情不為過吧?不要只是一直滑社群媒體或是 YouTube 的首頁我就過得心安理得。
Debug
入驻第1年
FAAS 调研笔记
FAAS 是什么 功能即服务 (FAAS) 是一类云计算服务,它提供了一个平台,允许客户开发、运行和管理应用程序功能,而 无需构建和维护通常与开发和启动应用程序相关的基础设施的复杂性。 构建遵循此模型的应用程序是实现“无服务器”体系结构的一种方式,通常在构建微服务应用程序时使用。 FAAS 最初是由 PiCloud 等各种初创企业在2010年左右提供的。 AWS Lambda 是大型公共云供应商提供的第一个 FAAS,随后是 Google Cloud Functions、Microsoft Azure Functions、IBM/Apache 2016年的 OpenWhisk (开源)和 2017 年的 Oracle Cloud FN(开源)。 国内的云厂商近几年也陆续提供 FAAS 产品,有阿里云 Serverless 服务、腾讯云云函数(Serverless Cloud Function,SCF)、华为云函数工作流(FunctionGraph)。 FAAS 优点 降低运营成本,开发人员不需要对服务器根据流量做规划,将部署平台的能力外包; 降低开发成本,Serverless 是整个应用程序组件商品化的结果,将功能相似的函数解耦,统一提供服务,减少重复建轮子; 扩展成本,Serverless 的架构就是将部署环境外包,水平扩张是完全自动、有弹性,并且有提供方来支持管理的; 偶尔的请求,一些提供给运营人员的操作很低频; 不一致的流量,函数扩容速度远远大于容器扩容速度,高效响应突发流量带来的扩容问题; 运营管理更轻松 容器的租户管理使得研发人员无需关心部署系统; 降低打包和部署的复杂性; 专注于业务代码,更快的迭代与部署; FAAS 缺点 控制权的转移,任何的外包策略,都会将部分的系统控制权移交到维护团队或组织,带来的就是不可控的系统停机、意外限制、成本变化、功能丧失、强制 API 升级等问题; 多租户问题,多个客户(租户)的多个软件在同一个机器上运行; 供应商锁定,一旦选择某个供应商或者维护团队,几乎是无法进行迁移的,代码的迁移大概率只能重构; 安全问题,会增加恶意攻击的剖面,增加攻击成功的可能性; 没有服务器内状态,持久化的数据无法在容器存储,只能借助第三方存储组件实现 cache; 测试问题,没有本地环境可以完全模拟云环境; 调试问题,云环境的调试目前还没有提供优秀的 tools; 业内 FAAS 的分支及发展 云服务商 产品 产品介绍 使用场景 客户案例 备注 AWS AWS Lambda AWS Lambda 是一项无服务器事件驱动型计算服务,该服务使您可以运行几乎任何类型的应用程序或后端服务的代码,而无需预置或管理服务器。 文件处理; 流处理;Web 应用程序;IoT 后端;移动后端; 可口可乐 西门子 Netflix Coinbase 阿里云 Serverless 工作流 Serverless 工作流(Serverless Workflow)是用来协调多个分布式任务执行的全托管 Serverless 云服务,简化开发、运行业务流程需要的任务协调、状态管理和错误处理等繁琐工作。用顺序、分支、并行等方式编排分布式任务,服务按照预设顺序协调任务执行,跟踪任务的状态转换,必要时执行用户定义的重试逻辑,确保工作流顺利完成。 多媒体文件处理场景;数据处理流水线场景;自动运维场景;解决运维无法可视化的问题; Serverless 应用引擎 SAE 是一个全托管、免运维、高弹性的通用 PaaS 平台。SAE 支持 Spring Boot、Spring Cloud、Dubbo、HSF、Web 应用和 XXL-JOB、ElasticJob 任务的全托管,零改造迁移、无门槛容器化、并提供了开源侧诸多增强能力和企业级高级特性。 微服务应用托管;弹性扩缩容场景;持续集成与交付; 贵州酒店集团 视野数科 爱奇艺体育 类似 side car ,用来管理应用,承接流量 Serverless 容器服务 ASK 是一款基于阿里云弹性计算基础架构,同时完全兼容 Kubernetes 生态,安全、可靠的容器产品。通过该产品,您无需管理和维护集群即可快速创建 Kubernetes 容器应用,并且根据应用实际使用的 CPU 和内存资源量进行按需付费,从而使您更专注于应用本身,而非运行应用的基础设施。 应用托管;在线业务弹性阔缩容数据计算 低成本支撑CI/CD任务执行 图森未来 越光医疗 腾讯云 云函数(Serverless Cloud Function,SCF) 腾讯云为企业和开发者们提供的无服务器执行环境,帮助您在无需购买和管理服务器的情况下运行代码。您只需使用平台支持的语言编写核心代码并设置代码运行的条件,即可在腾讯云基础设施上弹性、安全地运行代码。云函数是实时文件处理和数据处理等场景下理想的计算平台。 静态网站托管;构建 RESTful API;部署 Serverless 全栈 Web 应用;Serverless 全景录制方案; 腾讯视频 新东方 微信阅 腾讯教育 腾讯相册 百视通 猎豹移动 API网关 腾讯云 API 网关(API Gateway)是腾讯云推出的一种 API 托管服务,能提供 API 的完整生命周期管理,包括创建、维护、发布、运行、下线等。 Serverless HTTP;微服务整合;外部多端统一;业务整合;能力提供及售卖; 人人视频 江娱互动 腾讯视频 英孚教育 内部原理 FAAS 方向 运行架构 常规的一个服务在容器中启动的流程 FAAS 调用启动流程 在传统的服务启动或者是容器化的服务进行启动的是否,都是服务跟随者对应的平台(巨石架构的物理机器或者微服务化的 k8s 容器)的启动而启动,整个生命周期在 pod 的启动开始,在 pod 的关机下线操作结束,整个周期是比较长的,同时必须有实例存活(至少一台)来承接响应,研发人员除了需要关注自己的开发 code,还需要关注容器的大小、容量、数量等运维指标; Serverless 中的 FAAS 将研发人员最重要的业务逻辑抽离了出来,除了这部分需要去管理升级,剩下的都交由 FAAS 提供平台来提供服务,托管后的 FAAS 生命周期从 pod 的启动关机简化到了 执行函数 handler 的 init 以及执行函数时间,并且在一些低频的业务中,一些函数实例可以交由 FAAS 提供服务商进行回收,甚至在某些时间不起函数实例,当有事件进来之后在执行函数初始化及执行逻辑(因为函数初始化到可以服务的启动时间在 100ms 左右,当然不同语言以及不同的服务提供方的实现会影响这里的启动时间); 架构分层 其实理解起来比较简单,可以理解成我们的代码已经是与 PAAS 平台进行强解耦的结果了,我们的代码就是一部电视剧,一个操作系统安装了指定的视频播放器就可以播放我们的电视剧了,同理,我们现在只需要关心我们的函数内业务代码逻辑的定义,只要接口定义的按照封装平台的要求来开发即可,我们不需要关心运行的环境及系统,由于 runtime 已经到了 func 级别,热更新代码以及启动服务都是快速可以响应的。 Mesh 方向 综上,若 FAAS 代表着是“无服务器”架构的话,其实 Service Mesh 严格意义上不能称为是“无服务器”架构,它并不能将容器部署与代码部署隔离开,只是在服务响应中增加了一层代理,用来控制应用程序中服务请求的传递,可以使得服务到服务的通讯快速、可靠和安全。 运行架构 优点: 简化微服务和容器中服务之间的通信; 更容易的诊断通讯错误,发生在自己的基础设施层上; 支持加密、认证和授权等安全特性; 允许更快地开发、测试和部署应用程序; 放置在容器集群的边车代理可以有效的管理网络服务; 缺点: 运行时实例通过使用服务网格而增加; 每次服务的调用都要经过 sidecar proxy; 没有解决与其他服务或者系统的集成,以及路由类型或转换的映射; 网格管理的复杂性被抽象化和集中化; 架构分层 将调用限流、熔断、安全、服务注册与发现、服务管理等非业务逻辑的功能全部都放到 Sidecar 中去,本质上是一个管理性质进程在管理着业务逻辑性质的进程,进程之间的通讯使用的是 UDC(Unix domain socket)。 Reference https://en.wikipedia.org/wiki/Function_as_a_service https://serverless.aliyun.com/ https://cloud.tencent.com/product/scf https://www.huaweicloud.com/product/functiongraph.html https://martinfowler.com/articles/serverless.html https://aws.amazon.com/cn/lambda/ https://time.geekbang.org/column/article/226574 https://www.techtarget.com/searchitoperations/definition/service-mesh https://www.zhaohuabing.com/2018/03/29/what-is-service-mesh-and-istio/ 关注微信公众号,第一时间获取最新内容,让我们一起变得更强!Debug客栈:订阅本站· 文章归档· 我的项目· 友情链接· 我的使用· 飞湾计划· 摄影展集· 我的主页

© 2026 好站网HaoZhan.wang 1.5 版权所有

苏ICP备19065220号-4 萌ICP备20269980号 茶ICP备2026050346号 本站数据 版本历史 关于本站