一直有在關注k8s容器管理平台，不是因為對運維感興趣，而是它是雲原生，雲架構的一塊基石，我們可以看看bat在雲原生架構方面的推動和投入，相信以后軟件從已誕生就生長在雲上。
K8S，可能有些朋友認為k8s跟微服務沒有啥關系，這個的看你站在什么維度和視角去看待這個問題。尤其是.NETCORE平台，沒有像JAVASPRINGCLOUD這樣的全家桶，更沒有SPRINGCLOUDALIBABA這樣的最佳實踐一站式解決方案，很多技術棧都需要我們自己去踩坑、試錯、總結經驗，試問有幾個公司會去這樣投入？回到最初的問題，整套微服務架構體系，我們關注的是啥？服務生命周期管理、服務治理、Devops、容器化、集群網絡等等，雖然目前k8s在某些層面做的比較一般，比如服務治理能力，但是我們可以借助k8s的生態，通過sidecar的方式或者其他方式去幫我們完善k8s薄弱的地方，比如服務治理istio。
我這邊簡單畫了一張邏輯架構圖，為什么叫簡單？架構沒有銀彈，千變萬化，結合自己的業務和成本適合才是最好的，正常情況下外部網絡這一層反代是沒有的，這里我只是列出幾種情況。比如我可以拿掉外部網絡的反向代理，把流量直接打到ingress，又或者我把ingress拿掉，gateway通過nodeport方式暴露服務，外部網絡還是通過nginx反代，再或者雲服務商SLB方案，還是那句話適合才是最好的。可能有朋友會說這個架構就是專業的運維團隊都有一定難度，呵呵，確實是挺難的，如果都是基於二進制命令的方式部署，那確實需要玩的很溜，好在容器化技術日新月異，各種輔助工具，從而大大降低了技術門檻。比如以下集群部署，我們可以先通過adm或者二進制或者雲服務商部署k8s集群，再通過kubesphere或者雲服務商可視化工具部署其他服務，都是界面操作，包括大部分的yaml文件都會幫我們生成，我們只需要簡單修改就好，當然前提是對k8s架構有一定的了解。
k8s 集群，這里着重介紹下k8s內部網絡集群。整個集群入口通過ingress網關路由接入，ingress其實就是反代，我們把它當傳統反向代理看就對了，當然跟傳統反代還是有點區別，主要是性能和功能，具體看官網，地址
https://www.kubernetes.org.cn/ingress。ingress后面是ocelot網關，關於ocelot網關的功能我就不介紹了，限流、鑒權、路由...，github地址：
https://github.com/ThreeMammals/Ocelot，有興趣的可以自己下載代碼看看，在這里集成了ocelot主要是為了業務能更好的控制，最重要的一點ocelot是微軟官方團隊基於.NETCORE實現的開源產品，怎么也的支持不是么？雖然性能不是那么出色，但是定制性強。再往后就是BFF聚合器和業務服務，BFF聚合器是啥？Backend For Frontend（服務於前端的后端），通常叫用戶體驗適配器，通俗點說就是以簡單統一的方式為終端聚合業務。聚合器沒有啥特別的在這里其實就是webapi服務。舉個簡單列子，添加商品到購物車操作（這里有pc端和app端，多端之間肯定有特定需求），1.獲取商品信息，2.獲取購物車信息以及購物車里面商品，2.如果包含該商品+1操作，否則添加該商品到購物車。在這個業務場景里面，涉及到了兩個獨立的服務，商品服務、購物車服務，統一通過聚合服務操作，返回到前端。其他不需要聚合操作的業務，直接通過ocelot請求到service端，比如獲取商品列表信息。整個服務請求大概就到這吧，下面介紹下，基礎支撐服務。
認證授權，這么多服務不可能每個服務都寫一套認證授權代碼（當然你也可以統一通過ocelot或者ingress來做，同樣支持jwt token機制，但是一般我不會這么去做，盡量提高網關性能吧），而且需要支持多種不同類型的終端，異構平台，所以這里我們使用.NETCORE開源產品IDS4來實現我們的統一認證授權中心，基於jwtbearer token機制實現，並且ids4框架實現了80%以上的OAUTH2&OIDC協議規范，具體介紹可以看看這個文章
https://www.cnblogs.com/adair-blog/p/11410183.html。
熔斷降級，熔斷降級主要分兩個層面，網關和代碼，網關層面的就不介紹了，通過配置相關策略完成，代碼層面基於簡單輕量的Polly組件來完成，雖然沒有springcloudalibaba的sentinel組件強大（全程可視化），麻雀雖小五臟俱全，有精力的也可以基於它寫一個可視化界面包括dashboard（我沒去了解現在的最新版有沒有這功能）。github地址：
https://github.com/App-vNext/Polly，有段時間沒關注它了，github上的start9.6k，贊。
服務發現，整個集群里面我沒有部署任何服務注冊中心組件，consul或者zookeeper，那整個集群是怎么做到服務注冊發現調用的呢？這里主要是k8s里面的服務發現機制，我簡單介紹一下實現原理，整個集群內部業務服務部署的是clusterip網絡模型，Deployment類型的資源，通過kubectl終端，發送創建service命令到kubeapiserver（k8s核心組件之一），kubeapiserver將service信息寫入etcd（分布式服務發現組件），此時kubeproxy進程（本地進程）監控到etcd上service和pod信息的變更，然后寫入到ipvs/iptables規則里面，最終通過RR或者其他規則輪詢轉發，當然整個服務發現機制少不了coredns/kube-dns的參與。
配置中心，通過configmap注入的方式實現所有服務的配置管理，雖然目前沒有apollo強大，但是原生集成，實時性還好，支持ui配置，灰度發布等等，當然如果不想使用k8s組件configmap，也可以在集群里面部署apollo，zookeep三方組件幫我們實現統一的配置管理。
分布式日志，elk三個開源組件的縮寫，具體哪三個就不寫了，個人理解它主要應用場景是分布式環境下大數據，高吞吐，近實時，所以非常適合分布式架構下的日志管理中心，.netcore平台的三方日志組件也提供了相關接口，如nlog，serilog等。
緩存redis，如果是大型應用通過k8sStatefulSet資源部署cluster集群，一般規模的應用部署高可用集群即可。redis不僅僅只是給我們做緩存方案，甚至分布式id（這個具體看業務，現在比較受歡迎的是snowflakeid，雪花算法分布式id），分布式鎖，統計，布隆過濾器等等這些都會有應用，具體可以看看這個文章：
https://www.cnblogs.com/adair-blog/p/14728755.html。
消息中間件：消息中間件目前比較主流的有rabbitmq、kafaka、rocketmq等，各有利弊，.netcore搭配最多的一般是rabmq，可能其他兩個是java開發的吧，哈哈。在分布式架構里面它的主要業務場景就是異步、解耦。比較經典的幾個場景，支付訂單過期、通過三方機構轉賬操作等等。
服務鏈路跟蹤：在分布式環境下，服務調用鏈路復雜，排錯，監控困難，所以我們需要一款UI豐富的分布式鏈路監控服務。skywalking是apache基金會下面的一個開源APM項目，為微服務架構和雲原生架構系統設計，java平台開發的，支持多語言，並且.NETCORE也有實現代理客戶端SkyAPM-dotnet，github地址：
https://github.com/SkyAPM/SkyAPM-dotnet，有興趣的可以看看實現原理，其實它就是一個代理客戶端，注入到了.NETCORE中間件里面，實現埋點，然后通過配置實現無侵入請求鏈路數據采集，實現原理類似淘寶早期的“鷹眼”服務，很久沒關注它了，不知道發展的怎么樣了。
服務發布，k8s原生支持滾動發布（增量發布），也可以通過手段來實現藍綠發布（全量，一般不會這么用），還可以通過Isito來實現灰度發布（增量發布），最終集成jenkins來完成自動發布。已gitlab+jenkins+k8s為例：
自動化部署核心是jenkins，它是徹頭徹尾的一個插件系統，比如k8s相關操作，都是集成k8s插件完成的，最終通過pipeline流水線腳本按step步驟執行。
到此已經聊的差不多了，也快接近尾聲了，其實整套架構想要落地，還需要其他一些技術儲備，如Devops，持續交付它們也是基於k8s集群來完成，所以整套體系下來門檻主要就是k8s平台。k8s其實就是一個標准的微服務架構，功能很強大，技術體系也很龐大復雜，上面的架構如果對k8s技術棧生態很熟的話，可以直接通過sidecar的方式集成isito servicemesh服務網格，它是專門用來做服務治理的，只要你能hold住。