頭條技術號：實戰架構
交流郵箱：[email protected]
本文主要講述：
基於阿里雲自建kubernetes集群與微服務的生產實踐系列-1：整體架構-1
目錄：
(1).demo演示地址
(2).概述
(3).大綱
3.1.包含從傳統服務架構到容器化&微服務架構的整個過程
3.2.包含3.1中各個環節的細節探究與實踐
(4).基於阿里雲的整體混合架構
4.1.混合架構概覽
4.2.一個數據請求的完整週期
4.2.1.用戶請求->服務域名->阿里雲負載均衡
4.2.2.阿里雲負載均衡->openresty->阿里雲負載均衡
4.2.3.阿里雲負載均衡-> 真實服務
4.2.3.1.容器化服務路徑
4.2.3.2.非容器化服務路徑
(5)可觀察性/可視化/報警
5.1.可觀察性概覽
5.2.app服務可觀察性
5.3.ingress可觀察性
5.4.k8s可觀察性
5.5.openresty可觀察性
5.6.redis可觀察性
5.7.rocketmq可觀察性
5.8.特殊業務可觀察性
(6).容器化生產實踐相關
(7).開發框架簡述
7.1.相關技術選型
7.2.code demo
7.2.1.allinone-demo工程結構
7.2.2.code示例
7.2.2.1.allinoneRPCApplication示例
7.2.2.2.allinoneWebApplication示例
7.2.2.3.apollo配置中心
(8).筆者容器化相關實戰github
8.1.提供一個低成本容器化所有組件的最佳實踐
8.2.筆者生產實踐中使用/製作的jdk官方鏡像
8.3.本系列文章所涉及的相關資源的github備份
8.4.筆者生產實踐中的openresty高性能配置
(9).小結/感慨
(1).demo演示地址
注意，如果訪問8080提示403，有可能是你的IP觸發了筆者openresty的防封邏輯，請關注筆者微信公眾號後發消息給筆者，將你的IP提供給筆者進行配置。
目前可開放的演示地址：
apollo(容器化):
http://dev.apollo-portal.future.com:8080/signin
User: guest
Password: guest
grafana(容器化):
http://monitor-app.future.com:8080/
User: guest
Password: guest
需要配置host:
39.98.43.48 dev.apollo-portal.future.com
39.98.43.48 monitor-app.future.com
(2).概述
容器化技術與微服務體系的結合是未來後端的總體趨勢，可以極大的簡化開發流程與IT技術成本；
作為coder，不論是身處哪一個領域，都非常有必要了解容器化&微服務下的後端架構；
本系列文章由此而來，筆者將系統講述親身負責的kubernetes容器化&微服務的生產實踐；
(3).大綱
3.1.包含從傳統服務架構到容器化&微服務架構的整個過程
調研各類微服務技術體系 ->
確認技術選型 ->
自研適應kubernetes容器化的微服務框caf ->
服務遷移到微服務框架 ->
基於阿里雲自建多可用區的kubernetes集群 ->
討論&確認容器化過度方案&最終方案 ->
業務服務容器化 ->
基礎組件/基礎服務容器化；
貫穿始終的體系可觀察化(grafana/prometheus)；
3.2.包含3.1中各個環節的細節探究與實踐
(4).基於阿里雲的整體混合架構
4.1.混合架構概覽
高清圖片請從此處下載：
https://github.com/hepyu/kubernetes-microsvc-product-practice/blob/master/images/%E5%9F%BA%E4%BA%8E%E9%98%BF%E9%87%8C%E4%BA%91%E8%87%AA%E5%BB%BAkubernetes%E9%9B%86%E7%BE%A4%E4%B8%8E%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%9A%84%E7%94%9F%E4%BA%A7%E5%AE%9E%E8%B7%B5%E7%B3%BB%E5%88%97-1%EF%BC%9A%E6%95%B4%E4%BD%93%E6%9E%B6%E6%9E%84-1.jpg
圖例說明：
藍色：表示使用阿里雲提供的服務，如rds,鏡像服務等。
綠色：表示已經容器化的部分。
橘色：表示最終要容器化的部分。
混合架構的含義：
是一個過渡階段：指非容器化服務與容器化服務共存的架構，當然，最終非容器化的部分會全部容器化(圖例中橘色部分)。
整個架構基於阿里雲，公有云提供了很多實用/高可用的基礎設施，極大的節約了成本/操作複雜性。
4.2.一個數據請求的完整週期
對照3.1.中的混合架構圖。
4.2.1.用戶請求->服務域名->阿里雲負載均衡
用戶請求通過域名進入，DNS將域名解析到阿里雲的負載均衡；
在阿里雲上可以直接配置域名的DNS解析，將負載均衡的公網IP配置到DNS上，如果一個負載均衡不夠，多配置幾個。
4.2.2.阿里雲負載均衡->openresty->阿里雲負載均衡
在使用阿里雲負載均衡時，很多時候負載均衡會直接掛載到後端的業務服務上；
我們並沒有採用這種方式，而是中間又加了一層openresty，原因在於openresty可以額外處理很多feature，比如rewrite,prometheus監控(流量/qps等)，特別是IP防封邏輯，而這些feature在阿里雲負載均衡層面是不具備可操作性的；
openresty負責前述的各類feature處理和流量轉發，再次轉發到阿里雲負載均衡；這時的負載均衡將直接掛載真實的後端服務，且這時的負載均衡分為兩類，一類是掛載K8S容器內的服務，另一類是掛載非容器化服務。
4.2.3.阿里雲負載均衡-> 真實服務
這裡分兩條路徑，容器化的服務和非容器化的服務，其處理路徑是不同的；
4.2.3.1.容器化服務路徑
阿里雲負載均衡通過K8S集群內部的loadBalancer組件橋接到K8S內的ingress-nginx反向代理，再由ingress-nginx反向代理到容器內部的服務(k8s-service->k8s-pod)。
即：阿里雲負載均衡-> k8s-loadBalancer-> k8s-ingress-nginx -> k8s-service -> k8s-pod（container）。
4.2.3.2.非容器化服務路徑
這個就很簡單了，很傳統做法一樣，直接掛載實際服務(在阿里雲的負載均衡處配置)。
(5)可觀察性/可視化/報警
容器化時代下的微服務體系，對整個架構的可觀察性與可視化的要求極高，否則很難找到對應的問題觸發點。
舉一個例子，當容器內部的某個pod的p99延遲突然飈增到10秒，那麼如何判斷誘因？除了傳統的誘因外，在容器化的前提之下，還要考慮pod驅逐，cpu彈性伸縮等容器相關誘因。
再如，當基礎服務/組件容器化後，我們如何評估其在容器內部的健康狀態，可觀察性和可視化都是極其重要的手段，在一定意義上可以說是唯一手段。
我們使用grafana/prometheus做容器化/非容器化的可觀察性，可視化，及報警的手段，進行全方位無死角的可觀察度量。
使用釘釘連接k8s-prometheus的alert報警組件，這就是基於阿里雲構建容器&微服務的好處，這些零七八碎的東西非常磨人的。
注：我們目前生產環境的grafana/prometheus實際上還是存在一些低優先級的死角度量。
5.1.可觀察性概覽
App: 服務可觀察性
Ingress: ingress-nginx可觀察性
K8s: k8s集群可觀察性
Nginx: openresty可觀察性
Redis: redis可觀察性，包含cluster, standalone, 哨兵等模式。
5.2.app服務可觀察性
dashboard舉例：
5.3.ingress可觀察性
5.4.k8s可觀察性
Cluster舉例：
5.5.openresty可觀察性
Dashboard舉例：
5.6.redis可觀察性
Cluster舉例：
5.7.rocketmq可觀察性
mq集群全維度舉例：
5.8.特殊業務可觀察性
開發框架不覆蓋特殊業務的可觀察性，需要業務方自行實現：
以oss上傳服務為例：
還有阿里雲rds, elasticsearch，consul等組件的可觀察性，這裡不再一一羅列，後序都會另行開文詳細陳述。
(6).容器化生產實踐相關
這個會在後續的系列文章中逐步提供；由於內容太多，本文不做陳述。
(7).開發框架簡述
7.1.相關技術選型
我們並沒有採用springcloud全家桶，一方面沒有必要(複雜度考量)，另一方面我們關注的是簡單極致以及性能的高效；
最終我們選擇基於現有成熟的技術自研一套基於註解的開發框架；
RPC: 微博的motan
註冊中心：zookeeper
配置中心: 攜程的apollo
可觀察性/可視化： prometheus
限流：阿里的sentinel
JVM健康檢查：spring-boot-starter-actuator
mq: rocketmq
search: elasticsearch
緩存：redis
DB: mysql
DB連接池：阿里druid
鏈路追蹤：skywalking
包含但不僅僅限於上述選型。
7.2.code demo
雖然是我負責框架開發，但是我無權代碼開源，只能申述思想和demoCode，本文這裡只展示一下demo，具體細節後續另行開文。
7.2.1.allinone-demo工程結構
以allinone-demo舉例：
allinone-api: motanApi接口。
allinone-service: rpc工程，motain-provider。
allinone-web: web工程，motain-consumer。
7.2.2.code示例
allinone-demo中使用了所有的基礎組件/基礎服務；
完全基於註解；
遵循慣例重於配置的原則；
7.2.2.1.allinoneRPCApplication示例
業務開發者使用任何組件時只需要通過註解開啟，相關的配置全部在apollo，通過apollo自動注入。
使用時直接使用註解Autowired/Resource即可，但要注意名字，和註解中的聲明要對應，這裡便是遵循了慣例重於配置的原則。
7.2.2.2.allinoneWebApplication示例
code也是類似的，完全基於註解，全方位解放業務開發者，只需關注業務即可。
7.2.2.3.apollo配置中心
這裡簡單陳述，實際上apollo的使用也需要規劃的，不能隨意，從下圖中也可以看出規劃性。
關於apollo的生產實踐另行開文，也有很多工程講究。
下圖是本文demo的passport的apollo配置，可以看到配置的工程規劃：
(8).筆者容器化相關實戰github
8.1.提供一個低成本容器化所有組件的最佳實踐
同時維護筆者生產環境的容器化配置目錄；
本文中的demo演示地址所在的個人私服就是用這個github下的yaml文件搭建的單節點K8S集群；
https://github.com/hepyu/k8s-app-config
8.2.筆者生產實踐中使用/製作的jdk官方鏡像
https://github.com/hepyu/oraclejdk-docker-image
8.3.本系列文章所涉及的相關資源的github備份
https://github.com/hepyu/kubernetes-microsvc-product-practice
8.4.筆者生產實踐中的openresty高性能配置
https://github.com/hepyu/openrestry
(9).小結/感慨
容器化時代下的微服務看起來很美，當然實際上在生產實踐中確實也很美，但是對架構師的廣度和深度要求很高，要具備相當水準的後端全棧能力/思想，同時對架構師主動找活/找到有效活的能力有很高的要求，即具備自我發覺、自我完善的能力/思想。
筆者在總結的時候，碰到無數細節，在後續的系列文章中會逐步涉及所有筆者親歷的相關細節。
容器化時代下的架構師，必須是親歷一線的實踐者。
閱讀更多 實戰架構 的文章
