為什麼我要推薦你使用Core WebApi？

• 2020 年 3 月 15 日
• 筆記

2020年了，放眼望去，單體架構已經漸行漸遠，分佈式架構大行其道，微服務更是如火如荼。作為分佈式實施的基礎，跨進程通信的技術也是五花八門，為什麼Core WebApi越來越火，被眾多大牛們一直推薦？小編這就為你一一解答！

3種跨進程交互方式

01

基於第三方存儲共享的通訊

基於第三方存儲共享的通訊，數據庫/Redis/隊列等，特點是被動通訊，滿足及時性要求低的場景。

02

基於Http協議的服務

如WebService、WCF、WebApi，甚至還有ashx一般處理程序，使用最廣泛。

03

遠程調用模式

遠程調用模式，包括FX下的RPC和.NetCore下的gRPC，有使用限制和優異的性能。大部分的開發者和項目選型中，第二類是最為廣泛的。下文對gRPC和WebApi有細緻比對。

.Net下的服務選型

細想後我們不難發現，從最初的WebService一統江山，到.NetFramework3.0推出的集大成者WCF，卻在4.0的時候被更輕巧的WebApi所打敗。更好的REST風格支持(WCF也可以但很麻煩)，對移動端的友好支持等，甚至跟MVC同一個開發技術棧，這些理由很充分的讓技術團隊都傾向於使用WebApi。

Core WebApi的變化

WebApi剛出來時，大家都非常興奮，終於有原生的RESTful API了，但實踐中卻發現太多槽點，跟MVC框架同項目不同管道，鑒權授權參數綁定也很不友好，讓學習者苦不堪言。然而，這個在Core WebApi得到了轉變，和Asp.NetCore管道的統一，讓大家開發和學習成本都降低了，再加上跨平台的優勢，和全新中間件模式加成，毫不客氣地說，CoreWebApi已經成為當下服務的首選。

Core WebApi VS gRPC

這兩個是目前.Net Core下最熱門的分佈式通信方式了， gRPC是client/server模式通信的，支持流式通信，性能更高一些，相對的使用場景和實施成本也會高一些，REST的通用性更強，像典型的前後端分離架構，當下各公眾平台對外數據提供，都是選擇的REST接口，包括在微服務架構實施上，Core WebApi使用還是更廣泛一些。

4天學好Core WebApi

DAY1

上手實踐，宇宙第一IDE輕鬆建項目就能運行，然後把swagger啊，log4net啥配置起來，先感受下，當然，進階點的可以用Nginx來組集群負載均衡搭建，好好體會下REST的無狀態。

DAY2

內置IOC容器和middleware翻翻源碼理解一下，知道請求是怎麼處理怎麼流轉的，後面功能開發時才心裏有底(面試也輕鬆)。

DAY3

各種Filter擴展定製，像異常處理、鑒權授權、跨域、緩存壓縮等常見功能，都是基於Filter的AOP實現的，必須得紮實下。

DAY4

最後是框架組件整合了，搭建一套快速開發框架，整合下EFCore，autofac等，把JWT，數據格式定好，基本就萬事大吉了。