1、微服務簡介
微服務優點
- 服務組件化
每個服務獨立開發、部署，有效避免一個服務的修改引起整個系統重新部署 - 技術棧靈活
約定通信方式，是得服務本身功能實現對技術要求不再那么銘感 - 獨立部署
每個微服務獨立部署，加快部署速度，方便擴展 - 擴展性強
每個微服務可以部署多個，並且有負載均衡能力 - 獨立數據
每個微服務有獨立的基本組件，例如數據庫、緩存等
微服務缺點
- 溝通成本
- 數據一致性
- 運維成本
- 內部架構復雜性
微服務和單體應用
單體應用，易於部署、測試，但是會使得代碼膨脹，難以維護，構建和部署成本大，新人上手難
適用於微服務的框架：Spring Boots、Spring Cloud、Dubbo、Go-micro .....
2、K8s部署微服務考慮的問題
微服務架構圖
微服務間如何通信？
REST API、RPC、MQ（后兩者主流）。
微服務如何發現彼此？
通過注冊中心進行服務的注冊與發現。
組件之間怎么個調用關系？
微服務內部處理邏輯。
那個服務作為整個網站入口？
網關，即gateway（也是單獨的一個微服務）。
那些微服務需要對外訪問？
只需要網關gateway入口對外即可，
一般都是先為gateway創建svc，然后由Ingress指定到該svc。
微服務怎么部署？更新？擴容？
基於Kubernetes就可以輕易實現，
Kubernetes生來就是為了這些。
如何區分有狀態應用和無狀態應用？
無狀態應用：不考慮存儲，不維護有狀態信息，也不考慮和其它服務副本是否有關系。
有狀態應用：有固定存儲，維護集群狀態信息，例如：mysql、mongodb，有狀態應用不建議部署到kubernetes。
為什么要用注冊中心？
微服務太多面臨的問題：
- 怎么記錄一個微服務多個副本接口地址？
- 怎么實現一個微服務多個副本負載均衡？
- 怎么判斷一個微服務副本是否可用？
主流注冊中心：Eureka，Nacos，Etcd；
注冊中心可基於statefulset部署到k8s集群中，也可以部署在集群外。
不同環境如何區分配置文件？
- configmap：通過不同的環境去掛載不同的配置文件
- entrypoint.sh：通過啟動腳本區分
- java -jar --spring.profiles.active=dev xxx.jar：基於啟動命令區分
- 統一配置中心，例如：Apollo，Disconf
3、項目遷移到k8s流程
-
制作鏡像（應用程序、運行環境、文件系統）
基礎鏡像：Debian 或 應用程序的運行環境鏡像
應用程序：Go，Java，Python ....
運行環境：不同的語言都需要有特定的運行環境（例如java需要jdk）
文件系統：忽略 -
控制器管理Pod
Deployment：無狀態部署
StatefulSet：有狀態部署（MySQL、Mongodb、Redis ...）
DaemonSet：守護進程部署
Job & CronJob：批處理 -
暴露應用
Service定義了Pod的邏輯集合和訪問這個集合的策略，
Service引入為了解決Pod的動態變化，提供服務發現和負載均衡，
支持Cluster IP，NodePort以及LocalBalancer三種類型，
Service的底層實現主要實現有iptables和ipvs兩種網絡模式，推薦ipvs，
使用CoreDNS解析Service名稱，
通過Label關聯Pod。 -
對外發布應用（ingress）
通過Service關聯Pod，
基於域名訪問，
通過Ingress Controller實現Pod的負載均衡（支持TCP/UDP 4層和HTTP 7層）。
最后在Ingress前面部署外網用戶統一入口實現七層代理/四層轉發（Nginx、HaProxy...） -
日志采集
Pod在運行的時候會產生應用日志，需要將其日志文件信息采集到統一的數據庫中存儲，然后從一個平台中展示
易給開發查閱日志信息和錯誤日志信息，易於排查問題
主流方案：FileBeat + ELK（高性能和解耦：+kafka） -
監控
不管是k8s集群Master還是Node，以及Pod，我們需要知道它們運行的具體狀況，
占用多少資源，剩余多少資源，就得通過監控的方式去實現。
主流方案：Prometheus + Grafana + ...Export