腾飞答不忘初心的三个问题
去年的時候有同學在微信上問了我3個問題，我覺得非常有代表性，當時沒有回答。主要是通過簡短的語言無法全面表述可能會產生歧義，所以決定專門寫一篇文章來表達一下我的想法，需要說明的是以下內容只是以我個人的經驗給大家一些參考。
初心同學的第一個問題：
我現在有兩三個問題，第一個，您覺著NetCore會火起來嗎，或者說會比現在好嗎，現在政府部門各種國產化是事實。好像確實比較認java，畢竟政府部門，有一定的風向標作用
這是第一個問題，但它并不是一個問題，實際上它包括了如下問題：
.NetCore會火起來嗎？或者說會比現在更好嗎？
政府部門認Java嗎, 在國內算是計算機語言的風向標嗎？
初心同學的第二個問題：
嗯嗯，第二個，您是怎么看今年各大互聯網裁員的事情，程序員年紀大了，注定被裁員嗎，您覺著裁員潮會波及范圍很大嗎，二線目前沒看出影響，之前我在北京來著，回石家莊一年了
互聯網公司裁員是怎么回事？?
二線城市的程序員發展與生存問題？
初心同學的第三個問題：
最后這個，我描述不清楚。您覺著怎么才算一個優秀的coder。因為很多程序，3年左右的程序員，慢慢寫，只要用心，也能寫的差不多。5年左右的可能代碼寫的更好些，效率更高點，也可能兩者都寫出要求的最優代碼。
怎樣才算一個優秀的coder??
職業規劃的問題?
列出來之后一看，這位同學是想框我，這明明是6個問題呀。好吧，我們第一個開始說起。
.Net Core會火起來嗎？
當然，肯定。一定會越來越好。
為什么如此肯定？第一主要是因為已經不能再壞到哪里去了，過去十年是互聯網和移動互聯網的黃金十年，C#沒有被當作主要語言被廣泛使用。在諸多原因的影響下原來那些使用C#語言作為主要開發語言的一線互聯網公司也逐漸開始將新的項目切換成使用Java來開發。而移動互聯網的浪潮也已經見頂，到了這個時候，可以說該轉的和該換的也都換了。?
如果說不能更壞了，那它為什么會變好呢? 因為它值 。我想我在這里就不用數據和實例來舉證了，網絡上有很多再者這本來就是一篇主觀的文章。ASP.NET Core彌補了之前不能跨平臺的不足，同時又完全開源，再加上性能高和語法簡潔優雅、模塊化設設計等諸多特性。從.net core3.1版本來看將grpc提到一等公民的位置上可見.net core布局高遠，并且腳踏實地地走在了前面。我們完全可以相信asp.net core會是最好的web框架之一。?
更何況還有服務網格的加持。服務網格是什么？如果你開發一個單體的應用，ASP.NET Core做為Web框架來做API的實現，如果你開發的是一個大型分布式應用，那么后端除了服務的開發你必然會考慮這些事情：
服務之前如何通信（HTTP？，同步還是異步）
服務注冊與發現?
服務追蹤?
服務通信容錯（重試/超時/熔斷/限流）
...
當然一個大型分布式應用肯定不止僅僅考慮上面的問題，但是這些是最基礎的問題。對應SpringCloud全家桶他們有拿來就用的方案 。
我們真的需要這樣的微服務框架嗎？那些主流的微服務框架，不管是類庫性質的Finagle、Hystrix，還是框架性質的Spring Cloud、Dubbo，本質上都歸于應用內解決方案，都存在以下三個問題：
技術門檻高：
隨著微服務實施水平的不斷深化，除了基礎的服務發現、配置中心和授權管理之外，團隊將不可避免的在服務治理層面面臨各類新的挑戰，包括但不限于分布式跟蹤、熔斷降級、灰度發布、故障切換等，這對團隊提出了非常高的技術要求。
多語言支持不足：
對于稍具規模的團隊，尤其在高速成長的互聯網創業公司，多語言的技術棧是常態，跨語言的服務調用也是常態，但目前開源社區上并沒有一套統一的、跨語言的微服務技術棧。
代碼侵入性強：
主流的微服務框架（比如Spring Cloud、Dubbo）或多或少都對業務代碼有一定的侵入性，框架替換成本高，導致業務團隊配合意愿低，微服務落地困難。
這些問題加起來導致的結果就是，在實施微服務的過程中，小團隊Hold不住，大公司推不動。針對微服務有3個版本的說法：
微服務 1.0，僅使用注冊發現，基于 SpringCloud 或者 Dubbo 進行開發，目前意圖實施微服務的傳統企業大部分處于這個階段，或者正從單體應用，向這個階段過渡，處于 0.5 的階段；
微服務 2.0，使用了熔斷，限流，降級等服務治理策略，并配備完整微服務工具和平臺，目前大部分互聯網企業處于這個階段。傳統企業中的領頭羊，在做互聯網轉型的過程中，正在向這個階段過渡，處于 1.5 的階段；
微服務 3.0，Service Mesh 將服務治理作為通用組件，下沉到平臺層實現，使得應用層僅僅關注業務邏輯，平臺層可以根據業務監控自動調度和參數調整，實現 AIOps 和智能調度。目前一線互聯網公司在進行這方面的嘗試。
從0.5到2.0是一個痛苦的過程，現在所有的大型互聯網公司包括BAT和TMD基本都走過，也只有他們的體量才可以支撐這樣的人力、財力在期望的時間內完成。對于其它的中小企業來說，可能會因為技術調整而錯失最佳的發展時機。
而好消息是，由于服務網格中基礎設施層抽象的特性， 從0.5到3.0可以跳過 1.0和2.0。享受BAT級別的基礎設施以及提供7*24小時的高可用服務不再像以前那樣難。?
服務網格作為 sidecar 運行，對應用程序來說是透明，所有應用程序間的流量都會通過它，所以對應用程序流量的控制都可以在 service mesh 中實現。
eShopOnContainers是ASP.NET Core官方團隊做了一個基于微服務架構的示例項目，現在最新版本已經加入了grpc和服務網格(Service Mesh)的支持。
也許ASP.NET Core目前沒有這樣可以拿來就用的全家桶，但是隨著服務網格趨于成熟，ASP.NET Core在大型分布式服務的技術選型上“生態不足”這一短板可以被劃掉了。
雖然ASP.NET Core會是更好的web框架，但是它沒有可能去挑戰Java的地位。存量只會穩定地延續，而增量來自于5G、AR以及AI這些新興市場，也可以說是下一個大的浪潮。它們會以怎樣的形式到來，我們會不會參與其中，沒有人知道。也取決于.NETer開發者本身這個群體有多少優秀的領導者能夠在未來的市場中做出一些成績。我們也許可以把眼界放的更開闊一些，多了解一些，借著過去吃過的虧在將來贏一些勝算。
另外我還有一個小小的建議：
不要局限于語言?
不要覺得c#寫起來順手就以為用C#開發效率高（可能真的只是因為你寫順手了）python、go也都是非常好的開發語言，要是你也寫順了，也會發現他們在解決某類問題的時候會更容易。
多了解一些工作行業之內，程序之外的事情?
除了寫代碼再多了解一下你們的產品，至少知道它的盈利模式是什么？用戶是不是在增長。如果公司是項目制的，就看看項目的利潤率大概是多少。即使是純技術路線的專業或者架構師路線，也很難在脫離業務、產品和的基礎之上走上高階的水平。更何況，這有助于我們更好地理解真實的世界，那個世界和代碼里構建的世界不同。
等等，你不是說一個建議嗎？
難道你可以一個問題里面多問，我就不可以一個建議里面多提嗎 :)?
總結
以上是生活随笔為你收集整理的腾飞答不忘初心的三个问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《ASP.NET Core 微服务实战》
- 下一篇： 用 C# 写一个 Redis 数据同步小