## 微服務平臺架構設計

## 云原生應用開發和部署的四大原則
云原生應用所構建和運行的應用,旨在充分利用基于四大原則的云計算模型。

云原生應用開發所構建和運行的應用,旨在充分利用基于四大原則的云計算模型:
* 基于服務的架構:基于服務的架構(如微服務)提倡構建松散耦合的模塊化服務。采用基于服務的松散耦合設計,可幫助企業提高應用創建速度,降低復雜性。
* 基于API 的通信:即通過輕量級 API 來進行服務之間的相互調用。通過API驅動的方式,企業可以通過所提供的API 在內部和外部創建新的業務功能,極大提升了業務的靈活性。此外,采用基于API 的設計,在調用服務時可避免因直接鏈接、共享內存模型或直接讀取數據存儲而帶來的風險。
* 基于容器的基礎架構:云原生應用依靠容器來構建跨技術環境的通用運行模型,并在不同的環境和基礎架構(包括公有云、私有云和混合云)間實現真正的應用可移植性。此外,容器平臺有助于實現云原生應用的彈性擴展。
* 基于DevOps流程:采用云原生方案時,企業會使用敏捷的方法、依據持續交付和DevOps 原則來開發應用。這些方法和原則要求開發、質量保證、安全、IT運維團隊以及交付過程中所涉及的其他團隊以協作方式構建和交付應用。
# 應用層微服務改造注意事項
- 應用框架推薦使用
- 微服務框架:spring boot、service mesh (istio)
- 東西流量使用HTTP
- 提供應用的健康檢查API:/api/v1/checkhealth
- 服務發現方法
- 推薦使用 k8s 原生service 網絡
- 不推薦使用 spring cloud Euraka
- 應用配置管理
- 建議使用配置中心Nacos
- 不建議使用本地文件profile
- 應用無狀態,支持橫向擴容

## 基礎服務平臺設計


- Jenkins【持續集成】
- Prometheus【監控系統】
- ELK 【日志分析系統】
- Jumpserver【堡壘機】
- Nexus 【制品倉庫】
- SWR 【容器鏡像倉庫】
- LDAP 【統一身份認證】
- DNS 【私有DNS】
- APM 【應用性能分析】
- Ansible 【基礎服務管理】
?
## jenkins CI/CD 流程
### 視頻演示
- Jenkins 用戶權限管理
- 支持RBAC 角色權限管理
- 授權開發者管理只屬于自己任務job:查看、發布、重構
- 構建任務區分應用環境:Dev、Sit、Uat、Prd
- Jenkins pipeline 全流程自動化發布
- ansible 自動化發布ingress 資源
### Jenkins CI/CD 流程

1. pull代碼
2. 測試registry,并登陸registry.
3. 編寫應用 Dockerfile
* dockerfile 對應用代碼無侵入,可以實時修改。
4. 構建打包 Docker 鏡像
5. 推送 Docker 鏡像到倉庫
6. 持續發布至容器集群
* 支持自動化自定義渲染多種K8S 資源類型:deployment、statefulset、pvc、configmap
* 持續發布支持常見集成工具:helm、kustomize、argocd
* 應用發布支持多環境部署:區分namespace、集群、權限審核
* 支持微服務應用一件發布
7. Deployment 部署模板設計
* 鏡像ID:使用8位Commit ID
* 啟動探針:存活探針、啟動探針、業務探針
* 應用cpu mem資源限制:limit、request
8. 檢查應用狀態
[JenkinsCI/CD實踐參考文檔](http://www.hmoore.net/huyipow/jenkins/748973)
### 應用資源分配規則
cat ftc_demo_limitRange.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: ftc-demo-limit
namespace: ftc-demo
spec:
limits:
- max : # 在一個pod 中最高使用資源
cpu: "2"
memory: "6Gi"
min: # 在一個pod中最低使用資源
cpu: "100m"
memory: "2Gi"
type: Pod
- default: # 啟動一個Container 默認資源規則
cpu: "1"
memory: "4Gi"
defaultRequest:
cpu: "200m"
memory: "2Gi"
max: #匹配用戶手動指定Limits 規則
cpu: "1"
memory: "4Gi"
min:
cpu: "100m"
memory: "256Mi"
type: Container
限制規則說明
* CPU 資源可以超限使用,內存不能超限使用。
* Container 資源限制總量必須 <= Pod 資源限制總和
* 在一個pod 中最高使用2 核6G 內存
* 在一個pod中最低使用100m核 2G 內存
* 默認啟動一個Container服務 強分配cpu 200m,內存2G。Container 最高使用 1 cpu 4G 內存。
* 如果用戶私有指定limits 規則。最高使用1 CPU 4G內存,最低使用 cpu 100m 內存 256Mi
默認創建一個pod 效果如下
kubectl describe pod -l app=ftc-saas-service -n ftc-demo
Controlled By: ReplicaSet/ftc-saas-service-7f998899c5
Containers:
ftc-saas-service:
Container ID: docker://9f3f1a56e36e1955e6606971e43ee138adab1e2429acc4279d353dcae40e3052
Image: dl-harbor.dianrong.com/ftc/ftc-saas-service:6058a7fbc6126332a3dbb682337c0ac68abc555e
Image ID: docker-pullable://dl-harbor.dianrong.com/ftc/ftc-saas-service@sha256:a96fa52b691880e8b21fc32fff98d82156b11780c53218d22a973a4ae3d61dd7
Port: 8080/TCP
Host Port: 0/TCP
State: Running
Started: Tue, 21 Aug 2018 19:11:29 +0800
Ready: True
Restart Count: 0
Limits:
cpu: 1
memory: 4Gi
Requests:
cpu: 200m
memory: 2Gi
### 生產案列
apiVersion: v1
kind: LimitRange
metadata:
name: jccfc-prod-limit
namespace: jccfc-prod
spec:
limits:
- max: # pod 中所有容器,Limit值和的上限,也是整個pod資源的最大Limit
cpu: "4000m"
memory: "8192Mi"
min: # pod 中所有容器,request的資源總和不能小于min中的值
cpu: "1000m"
memory: "2048Mi"
type: Pod
- default: # 默認的資源限制
cpu: "4000m"
memory: "4096Mi"
defaultRequest: # 默認的資源需求
cpu: "2000m"
memory: "4096Mi"
maxLimitRequestRatio:
cpu: 2
memory: 2
type: Container
## 監控系統介紹
- 基礎監控:是針運行服務的基礎設施的監控,比如容器、虛擬機、物理機等,監控的指標主要有內存的使用率
- 運行時監控:運行時監控主要有 GC 的監控包括 GC 次數、GC 耗時,線程數量的監控等等
- 通用監控:通用監控主要包括對流量和耗時的監控,通過流量的變化趨勢可以清晰的了解到服務的流量高峰以及流量的增長情況
- 錯誤監控:錯誤監控: 錯誤監控是服務健康狀態的直觀體現,主要包括請求返回的錯誤碼,如 HTTP 的錯誤碼 5xx、4xx,熔斷、限流等等
### Prometheus Arch


### 日志管理系統
### jumpserver 堡壘機使用說明
- admin: root管理員權限
- Developer: 開發這權限
# Devops標準化規范

## **目的**
為確保錦程業務訪問的安全性、統一性和可管理性,制定本管理規范。
- [域名管理規范]([http://www.hmoore.net/huyipow/devops/971142](http://www.hmoore.net/huyipow/devops/971142))
- Deployment容器規范
- 日志標準化規范
- 編譯和運行其標準
- 項目上線checklist
[標準化規范wiki連接](https://wiki.corp.jccfc.com/pages/viewpage.action?pageId=10584752)
## 域名管理規范
用途| 分類 | 域名 | 證書類型|DNS 解析范圍|API服務|
----|----|----|----|----|----|
外部客戶訪問網站、外部合作伙伴訪問API | 公網網站|jccfc.com 等業務對應域名|從互聯網CA采購SSL證書,及通配符SSL證書 |互聯網、內網|允許|
錦程內部用戶訪問網站 | 內部網站|corp.jccfc.com |等業務對應域名內部證書 客戶端證書認證|互聯網、內網|禁止
數據中心內部訪問、API調用等設備管理用途|內部域名|jccfc.io (各業務統一使用本域名)|無|允許
|K8S集群內服務與發現|ServiceName|Appid|無|K8S集群內|允許|
### k8S service 服務請求地址
請求地址格式
http://appid.namespace.svc.cluster.local:port
夸NameSpace
http://user.jccfc-uat.svc.cluster.local:8080/Seal/
同NameSpace訪問地址
http://user:8080/raWeb/CSHttpServlet
### spring cloud 接入詳細方案,簡單配置代碼無影響

* ① 去掉對Eureka連接
* ② SpringCloud的服務和對應Kubernetes服務的綁定
* ③禁用Eureka服務注冊,服務發現,禁用Hystrix等。
* 其中①和③都是通用的禁用Springcloud的功能,只有②是必要的對要訪問的服務進行適當配置。
## Deployment 容器規范
### Deployment
規范腳本在 jenkins 生成
- 應用提供健康檢查API:http://cms.corp.jccfc.com/api/v1/checkHealth
- 后端應用端口:8080
- 前端應用端口:80
## EFK實時日志查詢系統
### 概要:
實時收集和存儲各類日志,方便快速查看、分析日志,提供可視化圖表、以及基于日志內容監控告警
### 背景:
* 開發可登錄服務器查看日志,存在安全隱患
* 查看日志需要專門人員授予不同權限,消耗人力和時間
* 各個項目日志格式自己擬定,維護難度大
* 日志沒有滾動壓縮,占用磁盤空間
* 日志缺乏分析和監控
### 日志平臺架構:

### 功能:
* 日志自動發現、采集
* 日志自動解析,生成索引
* 日志自動生命周期管理
* 冷熱數據分離
* 可視化圖表
* 集群性能監控
* x-pack權限控制
### 容器內應用寫入路徑:
/volume_logs
### 節點掛在路徑
/opt/app_logs/{{ appid }}/app.log // 應用日志
/opt/app_logs/{{ appid }}/api-access.log // restful接口訪問日志
/opt/app_logs/{{ appid }}/rpc-access.log // rpc接口訪問日志
### 容器化應用
/volume_logs/app.log
/volume_logs/api-access.log
/volume_logs/rpc-access.log
## 編譯和運行期標準
### JDK Version 推薦使用1.8.0_191
| 版本 | 參數 |說明|
| --- | --- |---|
| 1.8.0\_131 | UseCGroupMemoryLimitForHeap | 堆內存限制
|1.8.0\_191 |ActiveProcessorCount| CPU 核數限制 |
|1.8.0\_191以上| XXInitialRAMPercentage=N|將初始堆大小設置為總內存的百分比|
|1.8.0\_191以上|XX:MinRAMPercentage=N|將最小堆大小設置為總內存的百分比|
|1.8.0\_191以上|XX:MaxRAMPercentage=N|將最大堆大小設置為總內存的百分比|
> 其中N是0到100之間的值,可以是“ double”類型。例如,12.3456。
* 容器內存 Request >= 1.25 \* JVM 最大堆內存 ;
* 容器內存 Limit >= 2 \* JVM 最大堆內存;
### maven && nexus
版本| 備注
---|---
3.6.1 | 推薦版本
后端應用倉庫 :https://nexus.corp.jccfc.com/repository/maven-public/
- sit: 使用snap 倉庫
- uat: 使用release 倉庫
- prod: 使用release 倉庫
前端應用倉庫地址:https://nexus.corp.jccfc.com/repository/npm_group/
## 項目上線checklist
### 目的
通過標準化部署要求,提升DevOps與開發團隊部署應用效率。保障項目上線穩定性。

### 上線流程
- 架構組審核
- DevOps 對接人分配項目負責人,明確指定項目Devops、DBA 負責人
- 完成項目上線
- 添加項目監控
- 添加日志索引
### appid 作用域
- 應用名稱
- git_repo
- es 索引名稱
- 監控服務名稱
- 訪問域名
### 編寫部署文檔
項目開發負責人參考下圖checklist要點,在項目code中編寫README文檔。

### 應用架構圖案例

## 配置變更流程
### 作用域
- 測試環境
- 生產環境
### 審批流程
- 一般事務變更
- ansible配置項修改。
- 提交 pull request,待運維管理員審批通過
- 執行變更

- 全局事務:
- 全局環境信息,參考以下審批流程
- ansible配置項修改
- 提交 pull request ,待運維管理員審批通過
- 郵件組成員商定變更時間
- 郵件成員:CTO、研發負責人、產品負責人 、運維負責人
- 確定變更時間后,全員郵件、微信組通知。既定時間內執行變更

### 應用故障評級

- 云原生應用
- 容器化微服務改造方案
- 應用容器化上線規范
- 服務網格和傳統應用區別
- DevOps 管理規范
- 基礎架構管理規范
- 域名管理規范
- 主機名稱管理規范
- 應用域名管理規范
- 應用上線規范
- GIT分支及API JAR上傳規范
- 基礎架構設計
- 運維管理職責
- 基礎服務
- DNS 內部架構
- centos 及 kernel 版本標準
- Linux服務器OS標準配置
- Docker版本初始化
- kuberneter 集群方案
- kubernetes 命名規范
- Jenkins CI/CD
- nginx 配置文件變更流程
- Prometheus 容器監控
- 項目資源需求
- 應用服務
- 編譯和運行期標準
- 新核心系統基礎服務架構
- 安全防御
- 互聯網軟件可靠性工程及可靠性度量