朱曄的互聯網架構實踐心得S2E7:漫談平臺架構的工做（基礎架構、基礎服務、基礎平臺、基礎中間件等等）

前言

程序開發畢竟還不是搬磚這種無腦體力勞動，須要事先有標準，有架構，有設計，絕對不是新公司今天創立，明天就能夠開始編碼的。其實不少公司在起步的時候沒有財力和資源建設獨立的基礎架構或平臺架構部門，甚至運維團隊都沒有，可是這不妨礙咱們心中有一個藍圖知道努力的方向，本文咱們就簡單聊聊平臺架構相關的工做內容（或者說做爲一個技術管理，應該去梳理、統1、明確的部分）的藍圖。因爲本文覆蓋的內容比較多，只能拋磚引玉大概提一些，沒法一一展開太詳細的東西。圖中的數字是我認爲的優先級，僅供參考。

規範

規範它雖然不是一個實際的代碼或組件，只是一個文檔，可是我以爲很是重要。沒有規範，那麼員工加下去任何一行新代碼可能都是錯的，整個研發流程也可能會由於沒有規範致使不少沒必要要的事故產生。

• 代碼提交&分支管理規範，咱們能夠在gitflow基礎上根據實際狀況（結合運維流程，項目複雜度，團隊人數，發佈週期）進行細化，涉及到：
  • 有哪幾個常駐分支，哪幾個臨時分支？
  • 分支命名規範？
  • 提交代碼描述規範？
  • 分支遷出和合並的時機？
  • 哪些分支普通開發沒有權限直接提交？
  • 測試用什麼分支，上線又用什麼分支？
  • 多版本並行開發如何提測？
  • Hotfix如何處理分支？
• 編碼規範，好比Java代碼能夠以阿里Java開發手冊爲基礎，你們一塊兒過一遍，針對項目的實際狀況（時間要求，對性能要求），選擇其中的一些堅定執行，而後補充一些其它的。咱們也可讓你們的IDE使用（導入）統一的Code Style Template來要求一致的編碼格式。由於Code Style的不一致致使提交的時候大範圍的代碼新增刪除徹底會污染提交，讓你們很難看出提交的代碼到底改了什麼。
• 數據庫設計規範。阿里Java開發手冊裏包含了一小部分數據庫設計規範，術業有專攻，這個仍是應該請資深DBA來給出必定的規範，包括但不限於：
  • 命名（表和字段前綴後綴命名，外鍵字段命名、通用字段命名統一）規範
  • 字段設計類型規範
  • 字段冗餘規範
  • 通用字段規範
  • 索引使用規範
  • ……。能夠參考《朱曄的互聯網架構實踐心得S2E1：業務代碼究竟難不難寫？》中提到的一些內容
• 項目結構規範，對於Java Maven項目來講基本目錄結構比較統一，對於其它語言的項目（好比Python），目錄結構沒有必定標準的話，項目源碼結構會千奇百怪，最好仍是對於項目結構有一個規範，包括：
  • 三層結構目錄劃分
  • 多環境（Profile）配置文件
  • 服務接口、服務實現、Web、Job模塊命名
• 最後是項目管理流程，有一些公司會有專門的PMO，有一些初創公司研發Leader也會充當PMO的角色，雖然這個活通常和平臺架構沒啥關係，無論怎麼樣，既然是項目確定少不了項目管理，做爲技術管理角色須要關注的一個點，項目管理流程也是比較重要的：
  • 迭代週期，迭代週期中的大環節大概發生的時間點
  • 開哪些會，開會時間點是？（日站會、周例會、啓動會、回顧會、覆盤會、排期會、PRD預評審會、PRD評審會、測試用例評審會、上線方案討論會）
  • 項目生命週期中每個角色產出哪些文檔？
  • 任務在哪裏管理，每個角色怎麼去維護任務狀態的流轉？不可能任務的每個狀態的流轉都由PMO來作

基礎框架

使用一些基礎框架來作應用開發是必須的，對於Java技術棧，你們所熟悉的框架有Spring Cloud全家桶、Spring Boot套件（封裝的各類starters）、Mybatis等，直接使用這些框架進行開發是能夠的，可是更建議的是由基礎架構團隊封裝本身的框架，本身作一層封裝，咱們能夠以相似Spring Boot Starter的模式，爲全部的組件封裝本身的Starter模塊，好處是：

• 方便進行統一的外部依賴類庫 & 庫版本管理和約定
• 方便針對公司內部狀況作更合適的自動配置（甚至實現0配置）
• 若是內部技術棧是異構的話，使用統一的框架有助於技術棧後端基礎設施的打通
• 爲全部的模塊打通監控，自動配置AOP作相應的攔截統一抓取獲取監控數據
• 模塊之間能夠相互整合和配合，實現1+1>2的效果
• 還有很重要的一點是，咱們能夠提供相應的管控後臺來配合框架使用，把框架的配置、管理和審計暴露在控制檯上

其實說白了，就是使用本身封裝的類庫佔坑，哪怕只是一層淺淺的封裝，也是頗有好處的，不只僅是作了各類統一（使用框架的統一，框架版本號的統一），更多的是由於佔了坑（固然，要擴展作Java agent動態字節碼注入的方式也是可行的，這種方式的缺點是沒有辦法提供API給業務使用），之後直接能夠經過升級框架經過IOC組件替換+AOP直接作各類擴展（不須要再麻煩業務團隊了）。

咱們來看看這裏腦圖上大概列出的一些業務開發須要用到的常見模塊（能夠看一下咱們公司開源的框架https://github.com/ke-finance/summerframework ，固然開源出來的模塊比較少，實際內部封裝了這裏提到的全部模塊）：

• Web MVC：能夠基於Spring MVC進行封裝，增長一些模板引擎的支持等
• 數據訪問：能夠基於MyBatis或Mybatis Plus+Druid數據源進行封裝，作一些額外的功能，好比敏感數據加密保存
• RPC服務調用或微服務：能夠基於Dubbo或Spring Cloud（Feign+Eureka）進行封裝，在客戶端方面擴展一些更智能的LB算法，以及路由策略（好比灰度）等功能
• Web API：能夠在Spring MVC+Swagger UI基礎上實現功能，提供統一的RESTful服務端API的標準，好比規範化API版本、響應結構體自動包裝（自適應）、錯誤包裝、HATEOAS超媒體資源導航整合、數據加解密實現、Collection資源的規範化、自動的mock接口的實現等
• 配置：能夠基於攜程Apollo（https://github.com/ctripcorp/apollo ）客戶端進行封裝，作自動配置
• 消息：能夠封裝RabbitMQ、RocketMQ的客戶端實現統一的消息API，而後擴展事務消息（收發消息和業務邏輯本地事務在一個事務中處理）等功能
• 緩存：能夠基於CacheCloud（https://github.com/sohutv/cachecloud ）提供Redis緩存服務
• 調度：能夠封裝XXLJob（https://github.com/xuxueli/xxl-job/ ）或ElasticJob（http://elasticjob.io）提供調度服務
• 日誌監控：能夠基於Micrometer實現應用打點，找一個APM（Skywalking https://github.com/apache/skywalking 或Pinpoint https://github.com/naver/pinpoint ）整合trace功能，擴展logback作日誌脫敏，擴展Spring Boot Actuator Endpoint等功能
• 鎖：能夠基於Redisson封裝分佈式鎖，使用統一的API來提供內存鎖和分佈式鎖
• 分佈式事務：主要是兩塊，同步2PC分佈式事務處理（好比咱們開源的https://github.com/ke-finance/dts ），異步的saga思想的實現，參考https://github.com/eventuate-tram/eventuate-tram-sagas 。
• 彈性：流控+隔離+熔斷，考慮基於https://github.com/alibaba/Sentinel 來實現，能夠是獨立的模塊提供服務，也能夠整合到Web API或RPC模塊中去
• 安全：能夠基於Spring Security進行擴展，加入符合業務需求的風控策略進去

基礎平臺

基礎平臺（管理平臺）須要和基礎框架打配合，框架是開發的時候使用的，平臺更多的是開發或運維人員作技術運營時使用的。不少開源框架都已經提供了管理後臺，咱們須要作的可能只是一些小修改，好比包括：

• 打通公司內部本身的帳號登陸體系和權限體系
• 根據不一樣的環境（開發、測試、灰度、生產）部署多份管理控制檯
• 根據須要看是否須要作多租戶的改造，實現業務隔離

有些平臺是重流程的，這些可能須要自主開發，大概介紹一下腦圖上提到的這些：

• 配置平臺：若是使用了攜程Apollo，天然就是使用Apollo的管理後臺
• 微服務管理平臺：這裏我列出了兩個方面的工做，一個是服務中心，更多的是服務維護、管理、監控方面的功能，能夠基於Spring Cloud Admin進行改造；一個是服務集市，更多的是服務標準化方面的管理，好比服務上線須要的文檔，接入的監控系統，以及上線後統一的文檔中心，服務集市相似於App Store的概念
• 緩存平臺，若是使用了CacheCloud，可使用CacheCloud的管理後臺
• 日誌平臺，分爲兩塊，一塊是日誌收集展現基本ELK已是標準；還有一塊是日誌異常報警，能夠本身來開發，基於Kafka消費日誌異步作日誌篩選+聚合結合本身公司的IM和郵件體系作報警
• 數據庫管理平臺：
  • DDL/DML工做流：開發提交申請，主管審批，自動執行，外加自動的風險檢測，優化建議等
  • DDL/DML變動通知：方便大數據以及運營團隊針對感興趣的數據庫和表進行訂閱，在DDL應用到各個環境（測試、生產）的時候可以第一時間獲得通知能夠進行人工、自動處理（相似before，after Filter的概念）
  • 數據庫知識庫：有一個統一的地方查看數據庫的結構說明、字典枚舉的定義
  • 固然數據庫管理平臺還能夠進一步作數據庫監控、慢SQL優化緣由分析等功能
• 全鏈路追蹤平臺：好比若是使用Skywalking的話能夠實現它提供的管理臺，主要功能無非是依賴拓撲分析、Trace查看、服務性能分析等
• 指標查看平臺：分爲兩塊，Dashboard通常能夠考慮直接使用Grafana，報警的話雖然Grafana也有Alert可是仍是建議在更底層（數據源頭）去作，能夠基於流處理去作或基於定時拉的方式去實現

基礎中間件

中間件是指獨立部署的不具備業務邏輯耦合 的通用服務，存儲服務在廣義上歸到中間件也不是不能夠，這裏大概列了幾個典型：

• MQ代理（Broker，不是Proxy），好比RabbitMQ、RocketMQ、Kafka
• API網關，有不少開源的網關實現，好比Kong（https://github.com/Kong/kong ）、Spring Cloud Gateway，咱們也實現了一套https://github.com/ke-finance/tesla ，通常網關的主要功能是調用路由、協議轉換、調用編排，而後也會以插件和過濾器形式提供不少安全、彈性方面的擴展功能
• DB代理，好比相似https://github.com/flike/kingshard 和https://github.com/Qihoo360/Atlas 的MySQL Proxy，實現數據庫的讀寫分離、分表分庫、故障轉移、彈性處理、監控、SQL優化等功能
• ES集羣，也能夠理解爲中間件，畢竟ES其實作的就是基於Lucene的分佈式集羣管理工做

這些中間件雖然不少時候作的是Proxy背後的其它服務，可是節點自己極可能是有狀態的，也須要考慮中間件自己的高可用性問題。

基礎服務

通常而言若是公司具備多個項目的話，項目之間確定會用到一些通用的內部和外部能力，這些能力和業務邏輯沒有太多關係，能夠考慮把這些能力進行統一的封裝獨立部署以微服務形式提供出來，這樣全部項目均可以快速對接。

在這裏把基礎服務分爲了兩類，一類是沒有業務邏輯的純基礎服務，每每是對接封裝一個或多個外部服務通道，另一類是包含一些業務的業務基礎服務。對於第一類基礎服務你可能會想，既然是對接外部服務通道直接使用他們的SDK或服務是否是直接在業務系統使用那些三方SDK就行了，基礎服務是須要作什麼呢？我以爲基礎服務應該這麼封裝：

• 封裝外部服務的SDK，通常而言好比短信也好、推送也好、存儲也好，都會使用多家提供的服務作備份、降級，經過咱們的SDK提供統一的對內API，屏蔽不一樣SDK的API差別
• 提供一個服務端，在服務端作數據落地，落地的目的有幾個：
  • 方便和外部進行服務消費對帳
  • 方便出錯的時候查找緣由
  • 方便和外部服務同步調用狀態（好比短信到達）
  • 方便進行服務餘額預警
• 服務端除了作數據落地，由統一的服務端作出口的好處是：
  • 作權限控制，通常而言即便是公司內部的項目進行基礎服務的調用應該也是須要先申請再使用的，甚至須要作服務調用量的控制（相似在內部再實現一層SaaS）
  • 收斂調用源IP
  • 集中管理調用外部SaaS服務的密鑰
  • 外部服務的降級和切換策略更換比較方便
  • 給接入方作報警
• 作一個管理後臺，雖然外部服務提供方做爲SaaS產品通常都會有不錯的控制檯（其實更多的時候，不可能把外部服務的控制檯的權限放給全部人看，內部業務方看本身的基礎服務控制檯便可），可是咱們內部作一個管理後臺意義仍是很大的，主要的功能通常是：
  • 統一登陸
  • 帳號（包括Secret）申請和分配，以及配額、限流等配置（管理員權限）
  • 調用記錄（請求、結果）查看
  • 調用模板的配置（考慮一下是否是放開服務的使用，好比短信、郵件、推送通常是基於模板的，模板須要內部外部審覈後才能使用）

若是每個服務都有控制檯的話，能夠大大方便業務方的自主接入和問題排查，這是基礎服務封裝很是有價值的一個點，對於大點的公司內部項目衆多就更須要把基礎服務在內部進行SaaS化了，並且最好對於不一樣的基礎服務打通接入方（統一的地方來申請全部須要的基礎服務）。

這裏腦圖上大概列了一些常見的基礎服務和業務服務，每個公司根據本身的業務通常都會不盡相同，基礎服務包括：

• 短信：接入多個短信渠道，根據政策、費率、到達率等狀況路由
• 文件存儲：接入多個小文件存儲服務（好比七牛、騰訊雲），根據存儲服務提供的功能，文件大小、費率等狀況路由
• 郵件：接入內部和外部（好比SendCloud）的郵件服務，根據使用場景進行路由
• 推送：接入多個推送渠道（好比極光、個推），而且作用戶、設備的關係維護
• 惟一ID：全局惟一ID的生成
• 圖形、滑動、點擊、智能驗證碼：提供統一的驗證碼服務，能夠根據場景自動選擇驗證碼類型
• 電子簽章：接入多個電子簽章服務，根據費率等因素路由
• 地圖服務：接入多個外部地圖服務，根據功能以及接入方使用的地圖進行服務選擇

業務服務包括：

• RBAC權限控制：統一的RBAC配置後臺，以及方便的SDK
• 通用表單服務：根據後臺配置的表單自動生成界面，以及表單信息的收集
• 狀態機：能夠借鑑https://github.com/hekailiang/squirrel ，基於狀態(State)、行爲(Action)、轉移(Transition)、條件(Condition)等概念，構建基於數據庫的狀態機平臺
• 統一支付：聚合支付，業務方能夠快速接入多種支付渠道，而且統一支付能夠提供統一的SDK和H5來實現統一的支付收銀臺
• 工做流、爬蟲、SSO……不詳細說明了

工程效率

接下去也簡單提一下工程效率和運維範疇的事情，雖然這和平臺架構沒啥太大關係，可是這兩塊是很重要的技術基建工做：

• 源代碼倉庫：好比能夠選擇Gitlab或atlassian三件套的Bitbucket
• 內部類庫倉庫：好比Java的Maven倉庫，能夠本身搭建Nexus倉庫
• 項目管理平臺：能夠選擇SaaS產品（好比Tower、Teambition），比較有名的是atlassian三件套的Jira
• 知識管理平臺：能夠選擇SaaS或開源Wiki產品，比較有名的是atlassian三件套的Confluence
• Bug管理平臺：好比能夠選擇禪道或直接複用Jira
• 代碼質量分析：好比能夠搭建SonarQube平臺

運維

這裏提到的一些運維繫統相關工做有的公司是架構團隊來建設的，列一個大概：

• CI/CD平臺：通常而言須要本身結合公司的工做流程作一套CI/CD平臺（底層能夠基於Jenkins（或直接SSH+腳本）封裝），這個平臺須要結合公司的工做流程去作，好比誰能夠發起流程，每個發佈環節須要誰來審批，發佈時間窗口等等
• DNS平臺：通常會直接使用域名管理商的平臺或相似DNSPod這種平臺
• CMDB：通常都會根據本身的狀況自建平臺，進行運維各個層次相關資源的元數據以及配置管理
• 監控：通常會基於Prometheus+Grafana+Zabbix等開源項目來打造運維的基礎監控
• CDN平臺：通常是用雲的，好比七牛、又拍或三大雲服務的CDN均可以
• 集羣配置管理：這個不是指CMDB，是指批量進行集羣配置應用操做，管理操做的平臺，好比Chef、Puppet、Ansible、Fabric，通常也是基於開源改造封裝或直接用開源的
• 容器編排：好比K8S平臺，通常可能會基於k8s的API作一套本身的k8s管控平臺或選用相似Rancher這種更好用更高層的服務，徹底基於命令行的k8s運維不是很高效易用
• 容器鏡像倉庫：好比Docker私有倉庫Harbor

總結

好吧，的確一些中大型互聯網公司是有超過100個內部系統是和研發相關的，甚至須要有專門的導航網站來管理工程效率、運維、基礎框架、基礎服務、基礎中間件、基礎平臺的這些網站，這些系統自己的維護工做量也是不小的，一整理就會發現原來除了業務程序還有這麼多周邊的東西是爲研發服務的，歡迎你們針對本文的內容進行補充。