goframe, beego, iris和gin的區別有哪些

本篇內容介紹了“goframe, beego, iris和gin的區別有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

評估指標

橫向比較

• 以下部分對比參數涉及評分的部分，滿分總共按照10分為標準。

• 如果標記為"-"的部分，表示不支持或者需要引入第三方插件支持。

• 以下特性如果官網提供文檔則直接提供文檔地址，找不到文檔但是筆者知道有就會簡單標注。

• 各個"框架"功能特性實現不同，在文檔、功能、易用性上存在較大差異，各位朋友可自行查閱鏈接。

經驗分享

不同的需求場景，存在不同的選擇。選擇適合的工具，解決適合的問題。

開源不存在孰好孰壞之分，開源作者能夠本著開源精神給大家分享技術成果用以學習和使用，這本身就是一件非常不易并且值得稱道的事情。

最后，筆者在這里跟大家分享一下自己所在團隊的情況，以及在Golang技術棧轉型過程中所走的彎路，希望能在框架選型這一環節，能給大家作一定參考。

團隊最初痛點

團隊轉型Golang技術棧的一些背景。主要幾點：

1. 團隊后端最初的主要技術棧為PHP，由于業務發展需要，進行微服務改造。第一版微服務采用了PHP+JsonRpc的通信方式。

2. 隨著項目增多，公司也組件了自己的DevOps團隊，底層部署轉向了Docker+Kubernetes容器架構，并且引入了Golang技術棧。

3. 由于一些痛點，通過一段時間對PHP和Golang的比較，團隊決定快速轉型Golang技術棧，主要痛點如下：

1. PHP項目在業務復雜后、項目中后期的開發和維護成本整體偏高。主要原因還是其過高的靈活性，非結構化的變量設計，參差不齊的開發人員素質。

2. 上云容器化部署后，PHP的DevOps效率太低。復雜的Composer版本管理，超大的Docker鏡像大小，都影響著DevOps的效率。相比較而言，Golang效率極其高效。

3. JsonRpc通信協議設計下，接口的擴展性和靈活性很高，但服務之間很難快速確定接口的輸入與輸出定義，只能根據文檔和示例進行對接和維護。由于代碼和文檔分離，大部分場景下接口文檔維護往往滯后于接口變化。隨著服務的不斷增加，非結構化的通信協議管理使得服務接口的開發和維護成本進一步提高。

4. JsonRpc的通信協議本質基于HTTP1.x+Json，執行效率過低，算不上真正的微服務通信協議，很難對接上主流的服務治理框架。相比較基于HTTP2.x的gRPC協議有著成熟微服務開發框架和服務治理解決方案。

5. 業務梳理的考量，PHP到Golang技術棧的遷移，其實也是一次技術重構的契機，在技術重構的過程中也重新梳理業務系統設計，償還技術債務。

進一步的痛點

Golang確實足夠簡單，相比較其他的解釋類開發語言，沒有過多的語法糖和語言特性，因此團隊上手很快，并快速完成了一部分業務系統的技術重構。但隨之而來的是更加嚴重的痛點。主要幾點：

1. 輪子過多：Golang實在太簡單了，以至于我們的團隊成員爆發了壓抑許久的悶騷勁，充分發揮"造后不管"的造輪精神，開發/封裝了許多大大小小的輪子。這些輪子均能滿足最基本的功能，例如：日志、配置、緩存等等。但輪子并不是實現一個基礎功能的半成品就了事，需要保證功能性、穩定性、擴展性和可維護性，要能結合更多生產實踐驗證，更需要能夠長期維護、持續進行迭代改進。否則，就是一堆大小不一的成人玩具。造輪一時爽，維護火葬場。直到現在，我們還在為分散在100多個Golang項目中的數十個成人玩具做大統一的事情痛苦不已。當然，這個問題也跟組織架構和團隊管理也有很大關系。

2. 不成體系：

1. 我們堅信一個package只做一件事情，并且特地使用單倉庫包的形式進行包管理，相當于每個package都是獨立維護的git倉庫。其實單倉庫包和package設計并不存在必要性，反而獨立的單倉庫包提高了組件和框架的維護成本。

2. 這種單倉庫包設計難以形成技術體系，在團隊技術管理上，難以形成統一的技術框架。單倉包顯得很孤立，而一個技術體系的建立除了需要制定規范和標準，更需要技術框架來準確落地。一個成體系的、統一的技術框架，至少涉及到數十個基礎技術組件，不可能完全孤立設計。每一個package的基礎功能實現都很簡單，但是如何能夠統一組織在一起卻不是一件簡單的事情，這需要團隊的技術管理者需要有一定的技術底蘊、格局和前瞻性，而不是和普通開發者那樣眼界只能局限于package本身。

3. 這種孤立的單倉庫包設計，對于業務項目的規范化約束不強，每一個組件都可以獨立替換，也至于痛點1的問題越發嚴重（連日志組件都好幾套，雖然都滿足基本的日志規范設計）。最終，我們最初引以為傲的單倉庫包設計，最終變成了一堆散沙。例如，就連需要增加標準化的鏈路跟蹤功能，由于單倉庫包過于散亂和不統一，使得推進改進成本極其高昂。

4. 除了使得技術體系難以建立，技術規范難以準確落地之外，每個組件的易用性也設計得較差。舉個簡單例子，我們的日志組件、緩存組件、數據庫組件、HTTP/gRPC Server組件都需要對接配置管理功能，單倉包需要保證低耦合設計，因此開發者在使用的時候需要先手動讀取配置、并轉換為目標配置對象、并注入到對應的組件初始化方法中，隨后才能將該對象運用到業務邏輯中，若干個業務項目均是重復此步驟。其實goframe在這塊的易用性設計就挺不錯，每個包當然是獨立設計的，在統一的技術框架體系下，再獨立提供一個耦合的單例模塊將常用的對象進行單例化封裝，自動實現配置讀取、配置對象轉換、配置對象注入及組件對象初始化，開發者僅需要調用一個單例方法即可。而這個常用單例模塊，成為了我們技術框架體系的一部分，極大地提高了業務項目的開發和維護效率。

3. 版本不一致：在業務項目不斷增多之后，輪子版本不一致性也越來越明顯。什么是版本不一致？舉個例子。我們有個輪子叫做httpClient，總共發布了10來個版本；我們總共有100多個Golang項目，幾乎每個版本都在使用。我們提交了一個bug fix，卻難以讓所有項目都能更新。對其他的輪子也是類似的情況，況且我們也有數十個各種輪子，被各個項目獨立使用中。

經過反思總結，總結了以下幾點：

1. 團隊需要一個統一的技術框架，而不是東拼西湊的一堆單倉庫包。

2. 我們只需要維護一個框架的版本，而不是維護數十個單倉庫包的版本。

3. 框架的組件必須模塊化、低耦合設計，保證內部組件也可以獨立引用。

4. 核心組件嚴格禁止單倉庫包設計，并且必須由框架統一維護。

最終的抉擇

走過這么多彎路之后，我們決心建立一套成體系的Golang開發框架。除了要求團隊能夠快速學習，維護成本低，并且我們最主要的訴求，是核心組件不能是半成品，框架必須是上過大規模生產驗證的，穩定和成熟的。隨著，我們重新對行業中流行的技術框架做了技術評估，包括上面說的那些框架。原本的初衷是想將內部的各個輪子統一做一個成體系的框架，在開源項目中找一些有價值的參考。

后來找到了goframe，仔細評估和學習了框架設計，發現框架設計思想和我們的經驗總結如出一則！

這里不得不提一件尷尬的事情。其實最開始轉Golang之前（2019年中旬）也做過一些調研，那時goframe版本還不高，并且我們負責評估的團隊成員有一種先入為主的思想，看到模塊和文檔這么多，感覺應該挺復雜，性能應該不高，于是沒怎么看就PASS。后來選擇一些看起來簡單的開源輪子自己做了些二次封裝。

這次經過一段時間的仔細調研和源碼學習，得出一個結論，goframe框架的框架架構、模塊化和工程化設計思想非常棒，執行效率很高，模塊不僅豐富，而且質量之高，令人驚嘆至極！相比較我們之前寫的那些半成品輪子，簡直就是小巫見大巫。團隊踩了一年多的坑，才發現團隊確實需要一個統一的技術框架而不是一堆不成體系的輪子，其實人家早已給了一條明光大道，并且一直在前面默默努力。

經過團隊內部的調研和討論，我們決定使用goframe逐步重構我們的業務項目。由于goframe是模塊化設計的，因此我們也可以對一些模塊做必要的替換。重構過程比較順利，基礎技術框架的重構并不會對業務邏輯造成什么影響，反而通過goframe的工程化思想和很棒的開發工具鏈，在統一技術框架后，極大地提高了項目的開發和維護效率，使得團隊可以專心于業務開發，部門也陸續有了更多的產出。目前我們已經有大部門業務項目專向了goframe。平臺每日流量千萬級別。

“goframe, beego, iris和gin的區別有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！