本文已授權(quán)自骨灰級技術(shù)專家陳皓

原文：https://coolshell.cn/articles/21672.html

讀完受益匪淺，強烈推薦給大家，都是非常寶貴的經(jīng)驗，希望大家也有收獲！

工作 20 多年了，這 20 來年看到了很多公司系統(tǒng)架構(gòu)，也看到了很多問題，在跟這些公司進行交流和討論的時候，包括進行實施和方案比較的時候，都有很多各種方案的比較和妥協(xié)，因為相關(guān)的經(jīng)歷越來越多，所以，逐漸形成了自己的邏輯和方法論。今天，想寫下這篇文章，把我的這些個人的經(jīng)驗和想法總結(jié)下來，希望能夠讓更多的人可以參考和借鑒，并能夠做出更好的架構(gòu)來。另外，我的這些思維方式和原則都針對于現(xiàn)有市面上眾多不合理的架構(gòu)和方案，所以，也算是一種“糾正”……（注意，這篇文章所說的這些架構(gòu)上的原則，一般適用于相對比較復(fù)雜的業(yè)務(wù)，如果只是一些簡單和訪問量不大的應(yīng)用，那么你可能會得出相反的結(jié)論）

目錄原則一：關(guān)注于真正的收益而不是技術(shù)本身原則二：以應(yīng)用服務(wù)和 API 為視角，而不是以資源和技術(shù)為視角原則三：選擇最主流和成熟的技術(shù)原則四：完備性會比性能更重要原則五：制定并遵循符從標準、規(guī)范和最佳實踐原則六：重視架構(gòu)擴展性和可運維性原則七：對控制邏輯進行全面收口原則八：不要遷就老舊系統(tǒng)的技術(shù)債務(wù)原則九：不要依賴自己的經(jīng)驗，要依賴于數(shù)據(jù)和學習原則十：千萬要小心 X - Y ?問題，要追問最初的原因原則十一：激進勝于保守，創(chuàng)新與實用并不沖突原則一：關(guān)注于真正的收益而不是技術(shù)本身對于軟件架構(gòu)來說，我覺得第一重要的是架構(gòu)的收益，如果不說收益，只是為了技術(shù)而技術(shù)，而沒有任何意義。對于技術(shù)收益來說，我覺得下面這幾個收益是非常重要的：是否可以降低技術(shù)門檻加快整個團隊的開發(fā)流程。能夠加快整個團隊的工程流程，快速發(fā)布，是軟件工程一直在解決的問題，所以，系統(tǒng)架構(gòu)需要能夠進行并行開發(fā)，并行上線和并行運維，而不會讓某個團隊成為瓶頸點。（注：就算拖累團隊的原因是組織構(gòu)架，也不妨礙我們做出并行的系統(tǒng)架構(gòu)設(shè)計）是否可以讓整個系統(tǒng)可以運行的更穩(wěn)定。要讓整個系統(tǒng)可以運行的更為的穩(wěn)定，提升整個系統(tǒng)的 SLA，就需要對有計劃和無計劃的停機做相應(yīng)的解決方案（參看《關(guān)于高可用的架構(gòu)》）是否可以通過簡化和自動化降低成本。最高優(yōu)化的成本是人力成本，人的成本除了慢和貴，還有經(jīng)常不斷的 human error。如果不能降低人力成本，反而需要更多的人，那么這個架構(gòu)設(shè)計一定是失敗的。除此之外，是時間成本，資金成本。如果一個系統(tǒng)架構(gòu)不能在上面三個事上起到作用，那就沒有意義了。原則二：以應(yīng)用服務(wù)和 API 為視角，而不是以資源和技術(shù)為視角國內(nèi)很多公司都會有很多分工，基本上都會分成運維和開發(fā)，運維又會分成基礎(chǔ)運維和應(yīng)用運維，開發(fā)則會分成基礎(chǔ)核心開發(fā)和業(yè)務(wù)開發(fā)。不同的分工會導(dǎo)致完全不同的視角和出發(fā)點。比如，基礎(chǔ)運維和開發(fā)的同學更多的只是關(guān)注資源的利用率和性能，而應(yīng)用運維和業(yè)務(wù)開發(fā)則更多關(guān)注的是應(yīng)用和服務(wù)上的東西。這兩者本來相關(guān)無事，但是因為分布式架構(gòu)的演進，導(dǎo)致有一些系統(tǒng)已經(jīng)說不清楚是基礎(chǔ)層的還是應(yīng)用層的了，比如像服務(wù)治理上的東西，里面即有底層基礎(chǔ)技術(shù)，也需要業(yè)務(wù)的同學來配合，包括 k8s 也樣，里面即有底層的如網(wǎng)絡(luò)這樣的技術(shù)，也有需要業(yè)務(wù)配合的 readniess和 liveness 這樣的健康檢查，以及業(yè)務(wù)應(yīng)用需要 configMap 等等 ……這些東西都讓我感覺到所謂 DevOps，其實就是因為很多技術(shù)和組件已經(jīng)分不清是 Dev 還是 Ops 的了，所以，需要合并 Dev和 Ops。而且，整個組織和架構(gòu)的優(yōu)化，已經(jīng)不能通過調(diào)優(yōu)單一分工或是單一組件能夠有很大提升的了。其需要有一種自頂向下的，整體規(guī)劃，統(tǒng)一設(shè)計的方式，才能做到整體的提升（可以試想一下城市交通的優(yōu)化，當城市規(guī)模到一定程度的時候，整體的性能你是無法通過優(yōu)化幾條路或是幾條街區(qū)來完成的，你需要對整個城市做整體的功能體的規(guī)劃才可能達到整體效率的提升）。而為了做到整體的提升，需要所有的人都要有一個統(tǒng)一的視角和目標，這幾年來，我覺得這個目標就是——要站在服務(wù)和 對外API的視角來看問題，而不是技術(shù)和底層的角度。原則三：選擇最主流和成熟的技術(shù)技術(shù)選型是一件很重要的事，技術(shù)一旦選錯，那會導(dǎo)致整個架構(gòu)需要做調(diào)整，而對架構(gòu)的調(diào)整重來都不是一件簡單的事，我在過去幾年內(nèi)，當系統(tǒng)越來越復(fù)雜的時候，用戶把他們的? PHP，Python, .NET，或 Node.js 的架構(gòu)完全都遷移到 Java + Go 的架構(gòu)上來的案例不斷的發(fā)生。這個過程還是非常痛苦的，但是你沒有辦法，當你的系統(tǒng)越來越復(fù)雜，越來越大時，你就再也不能在一些玩具技術(shù)上玩了，你需要的更為工業(yè)化的技術(shù)。盡可能的使用更為成熟更為工業(yè)化的技術(shù)棧，而不是自己熟悉的技術(shù)棧。所謂工業(yè)化的技術(shù)棧，你可以看看大多數(shù)公司使用的技術(shù)棧，比如：互聯(lián)網(wǎng)，金融，電信……等等 ，大公司會有更多的技術(shù)投入，也需要更大規(guī)模的生產(chǎn)，所以，他們使用的技術(shù)通常來說都是比較工業(yè)化的。在技術(shù)選型上，千萬不要被——“你看某個公司也在用這個技術(shù)”，或是一些在論壇上看到的一些程序員吐槽技術(shù)的觀點來決定自己的技術(shù)，還是看看主流大多數(shù)公司實際在用的技術(shù)棧，會更靠譜一些。選擇全球流行的技術(shù)，而不是中國流行的技術(shù)。技術(shù)這個東西一定是一個全球化的東西，不是一個局域化的事。所以，一定要選國際化的會更好。另外，千萬不要被某些公司的“特別案例”騙過去了，那怕這個案例很性感，關(guān)鍵還是要看解決問題的思路和采用的技術(shù)是否具有普世性。只有普世性的技術(shù)有更強的生命力。盡可能的使用紅利大的主流技術(shù)，而不要自己發(fā)明輪子，更不要魔改。我見過好些個公司魔改開源軟件，比如有個公司同魔改mesos，最后改著改著發(fā)現(xiàn)自己發(fā)明另一個 kubernetes。我還見過很多公司或技術(shù)團隊喜歡自己發(fā)明自己的專用輪子，最后都會被主流開源軟件所取代。完全沒有必要。不重新發(fā)明輪子，不魔改，不是因為自己技術(shù)不能，而是因為，這個世界早已不是自己干所有事的年代了，這個時代是要想盡方法跟整個產(chǎn)業(yè)，整個技術(shù)社區(qū)融合和合作，這樣才會有最大的收益。那些試圖因為某個特例需要自成一套的玩法，短期沒問題，但長期來說，我都不看好。絕大多數(shù)情況下，如無非常特殊要求，選 Java基本是不會錯的。一方面，這是因為 Java 的業(yè)務(wù)開發(fā)的生產(chǎn)力是非常好的，而且有 Spring 框架保障，代碼很難寫爛，另外，Java 的社區(qū)太成熟了，你需要的各種架構(gòu)和技術(shù)都可以很容易獲得，技術(shù)紅利實在是太大。這種運行在JVM上的語言有太多太多的好處了。在 Java 的技術(shù)棧上，你的架構(gòu)風險和架構(gòu)的成本（無論是人力成本，時間成本和資金成本）從長期來說都是最優(yōu)的在我見過的公司中，好些公司的架構(gòu)都被技術(shù)負責人個人的喜好、擅長和個人經(jīng)驗給綁架了，完全不是從一個客觀的角度來進行技術(shù)選型。其實，從 0 到 1 的階段，你用什么樣的技術(shù)都行，如果你做一個簡單的應(yīng)用，沒有事務(wù)處理沒有復(fù)雜的交易流程，比如一些論壇、社交之類的應(yīng)用，你用任何語言都行。但是如果有一天你的系統(tǒng)變復(fù)雜了，需要處理交易了，量也上來了，從 1 到 10，甚至從 10 到 100，你的開發(fā)團隊也變大了，需要構(gòu)建的系統(tǒng)越來越大，你可能會發(fā)現(xiàn)你只有一個選擇，就是 Java。想想京東從.NET 到 Java，淘寶從 PHP 到 Java……原則四：完備性會比性能更重要我發(fā)現(xiàn)好些公司的架構(gòu)師做架構(gòu)的時候，首要考慮的是架構(gòu)的性能是否能夠撐得住多大多大的流量，而不是考慮系統(tǒng)的完備性和擴展性。所以，我已經(jīng)多次見過這樣的案例了，一開始直接使用 MongoDB 這樣的非關(guān)系型數(shù)據(jù)庫，或是把數(shù)據(jù)直接放在 Redis 里，而直接放棄關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)完備性的模型，而在后來需要在數(shù)據(jù)上進行關(guān)系查詢的時候，發(fā)現(xiàn) NoSQL 的數(shù)據(jù)庫在 Join 上都表現(xiàn)的太差，然后就開始各種飛線，為了不做 Join 就開始冗余數(shù)據(jù)，然而自己又維護不好冗余數(shù)據(jù)后帶來的數(shù)據(jù)一致性的問題，導(dǎo)致數(shù)據(jù)上的各種錯亂丟失。所以，我給如下的一些如下的架構(gòu)原則：使用最科學嚴謹?shù)募夹g(shù)模型為主，并以不嚴謹?shù)哪Ｐ妥鳛檠a充。對于上面那個案例來說，就是——永遠使用完備支持 ACID 的關(guān)系型數(shù)據(jù)庫，然后用 NoSQL 作補充，而不是完全放棄關(guān)系型數(shù)據(jù)庫。這里的原則就是所謂的“先緊后松”，一開始緊了，你可以慢慢松，但是開始松了，以后你想緊再也緊不過來了。性能上的東西，總是有很多解的。我這么多年的經(jīng)歷告訴我，性能上的事，總是有解的，手段也是最多的，這個比起架構(gòu)的完備性和擴展性來說真的不必太過擔心。為了追求所謂的性能，把整個系統(tǒng)的完備性丟失掉，相當?shù)氐貌粌斒АＴ瓌t五：制定并遵循符從標準、規(guī)范和最佳實踐這個原則是非常重要的，因為只有符從了標準，你的架構(gòu)才能夠有更好的擴展性。比如：我經(jīng)常性的見到很多公司的系統(tǒng)既沒有符從業(yè)界標準，也沒有形成自己公司的標準，感覺就像一群烏合之眾一樣。最典型的例子就是 HTTP 調(diào)用的狀態(tài)返回碼。業(yè)內(nèi)給你的標準是 200表示成功，3xx 跳轉(zhuǎn)，4xx 表示調(diào)用端出錯，5xx 表示服務(wù)端出錯，我實在是不明白為什么無論成功和失敗大家都喜歡返回 200，然后在 body 里指出是否error（前兩年我在微信公眾號里看到一個有一定名氣的互聯(lián)網(wǎng)老兵推薦使用無論正確還是出錯都返回 200 的做法，我在后臺再三確認后，我發(fā)現(xiàn)這樣的架構(gòu)師真是害人不淺）。這樣做最大的問題是——監(jiān)控系統(tǒng)將在一種低效的狀態(tài)下工作。監(jiān)控系統(tǒng)需要把所有的網(wǎng)絡(luò)請求包打開后才知道是否是錯誤，而且完全不知道是調(diào)用端出錯還是服務(wù)端出錯，于是一些像重試或熔斷這樣的控制系統(tǒng)完全不知道怎么搞（如果是 4xx錯，那么重試或熔斷是沒有意義的，只有 5xx 才有意義）。有時候，我會有種越活越退步的感覺，錯誤碼設(shè)計這種最基本最基礎(chǔ)的東西為什么會沒有？并且一個公司會任由著大家亂來？這些基礎(chǔ)技能怎么就這樣丟掉了？還有，我還見過一些公司，他們整個組織沒有一個統(tǒng)一的用戶 ID 的設(shè)計，各個系統(tǒng)之間同步用戶的數(shù)據(jù)是通過用戶的身份證 ID，是的，就是現(xiàn)實世界的身份證 ID，包括在網(wǎng)關(guān)上設(shè)置的用戶白名單居然也是用身份證 ID。我對這個公司的內(nèi)的用戶隱私管理有很大的擔憂。一個企業(yè)，一個組織，如果沒有標準和規(guī)范，也就會有抽象，這一定是要出各種亂子的。下面，我羅列一些你需要注意的標準和規(guī)范（包括但不限于）：服務(wù)間調(diào)用的協(xié)議標準和規(guī)范。這其中包括 Restful API路徑, HTTP 方法、狀態(tài)碼、標準頭、自定義頭等，返回數(shù)據(jù) JSon Scheme……等。一些命名的標準和規(guī)范。這其中包括如：用戶 ID，服務(wù)名、標簽名、狀態(tài)名、錯誤碼、消息、數(shù)據(jù)庫……等等日志和監(jiān)控的規(guī)范。這其中包括：日志格式，監(jiān)控數(shù)據(jù)，采樣要求，報警……等等配置上的規(guī)范。這其中包括：操作系統(tǒng)配置、中間件配置，軟件包……等等中間件使用的規(guī)范。數(shù)據(jù)庫，緩存、消息隊列……等等軟件和開發(fā)庫版本統(tǒng)一。整個組織架構(gòu)內(nèi)，軟件或開發(fā)庫的版本最好每年都升一次級，然后在各團隊內(nèi)統(tǒng)一。這里重要說一下兩個事：Restful API 的規(guī)范。我覺得是非常重要的，這里給兩個我覺得寫得最好的參考：Paypal?和Microsoft?。Restful API 有一個標準和規(guī)范最大的好處就是監(jiān)視可以很容易地做各種統(tǒng)計分析，控制系統(tǒng)可以很容器的做流量編排和調(diào)度。另一個是服務(wù)調(diào)用鏈追蹤。對于服務(wù)調(diào)用鏈追蹤來說，基本上都是參考于Google Dapper?這篇論文，目前有很多的實現(xiàn)，最嚴格的實現(xiàn)是Zipkin，這也是 Spring Cloud Sleuth 的底層實現(xiàn)。Zipkin 貼近 Google Dapper 論文的好處在于——無狀態(tài)，快速地把 Span 發(fā)出來，不消耗服務(wù)應(yīng)用側(cè)的內(nèi)存和 CPU。這意味著，監(jiān)控系統(tǒng)寧可自己死了也不能干擾實際應(yīng)用。軟件升級。我發(fā)現(xiàn)很多公司包括 BAT，他們完全沒有軟件升級的活動，全靠開發(fā)人員自發(fā)。然而，這種成體系的活動，是永遠不可能靠大的自發(fā)形成的。一個公司至少一年要有一次軟件版本升級的review，然后形成軟件版本的統(tǒng)一和一致，這樣會極太簡化系統(tǒng)架構(gòu)的復(fù)雜度。原則六：重視架構(gòu)擴展性和可運維性在我見過很多架構(gòu)里，技術(shù)人員只考慮當下，但從來不考慮系統(tǒng)的未來擴展性和可運維性。所謂的管生不管養(yǎng)。如果你生下來的孩子胳膊少腿，嚴重畸形，那么未來是很難玩的。因為架構(gòu)不是和軟件不是寫好就完的，是需要不斷修改不斷維護的，80%的軟件成本都是在維護上。所以，如何讓你的架構(gòu)有更好的擴展性，可以更容易地運維，這個是比較重要的。所謂的擴展性，意味著，我可以很容易地加更多的功能，或是加入更多的系統(tǒng)，而所謂可運維，就是說我可以對線上的系統(tǒng)做任意的變更。擴展性要求的是有標準規(guī)范且不耦合的業(yè)務(wù)架構(gòu)，可運維性要求的則是可控的能力，也就是一組各式各樣的控制系統(tǒng)。通過服務(wù)編排架構(gòu)來降低服務(wù)間的耦合。比如：通過一個業(yè)務(wù)流程的專用服務(wù)，或是像 Workflow，Event Driven Architecture ， Broker，Gateway，Service Discovery 等這類的的中間件來降低服務(wù)間的依賴關(guān)系。通過服務(wù)發(fā)現(xiàn)或服務(wù)網(wǎng)關(guān)來降低服務(wù)依賴所帶來的運維復(fù)雜度。服務(wù)發(fā)現(xiàn)可以很好的降低相關(guān)依賴服務(wù)的運維復(fù)雜度，讓你可以很輕松的上線或下線服務(wù)，或是進行服務(wù)伸縮。一定要使用各種軟件設(shè)計的原則。比如：像SOLID這樣的原則（參看《一些軟件設(shè)計的原則》），IoC/DIP，SOA 或 Spring Cloud 等 架構(gòu)的最佳實踐（參看《SteveY對Amazon和Google平臺的吐槽》中的 Service Interface 的那幾條軍規(guī)），分布式系統(tǒng)架構(gòu)的相關(guān)實踐（參看：《分布式系統(tǒng)的事務(wù)處理》，或微軟件的 《Cloud Design Patterns》）……等等原則七：對控制邏輯進行全面收口所有的程序都會有兩種邏輯，一種是業(yè)務(wù)邏輯，一種是控制邏輯，業(yè)務(wù)邏輯就是完成業(yè)務(wù)的邏輯，控制邏輯是輔助，比如你用多線程，還是用分布式，是用數(shù)據(jù)庫還是用文件，如何配置、部署，運維、監(jiān)控，事務(wù)控制，服務(wù)發(fā)現(xiàn)，彈性伸縮，灰度發(fā)布，高并發(fā)，等等，等等 ……這些都是控制邏輯，跟業(yè)務(wù)邏輯沒有一毛錢關(guān)系。控制邏輯的技術(shù)深度會通常會比業(yè)務(wù)邏輯要深一些，門檻也會要高一些，所以，最好要專業(yè)的程序員來負責控制邏輯的開發(fā)，統(tǒng)一規(guī)劃統(tǒng)一管理，進行收口。這其中包括：流量收口。包括南北向和東西向的流量的調(diào)度，主要通過流量網(wǎng)關(guān)，開發(fā)框架 SDK或 Service Mesh 這樣的技術(shù)。服務(wù)治理收口。包括：服務(wù)發(fā)現(xiàn)、健康檢查，配置管理、事務(wù)、事件、重試、熔斷、限流……主要通過開發(fā)框架 SDK - 如：Spring Cloud，或服務(wù)網(wǎng)格Service Mesh等技術(shù)。監(jiān)控數(shù)據(jù)收口。包括：日志、指標、調(diào)用鏈……主要通過一些標準主流的探針，再加上后臺的數(shù)據(jù)清洗和數(shù)據(jù)存儲來完成，最好是使用無侵入式的技術(shù)。監(jiān)控的數(shù)據(jù)必需統(tǒng)一在一個地方進行關(guān)聯(lián)，這樣才會產(chǎn)生信息。資源調(diào)度有應(yīng)用部署的收口。包括：計算、網(wǎng)絡(luò)和存儲的收口，主要是通過容器化的方案，如k8s來完成。中間件的收口。包括：數(shù)據(jù)庫，消息，緩存，服務(wù)發(fā)現(xiàn)，網(wǎng)關(guān)……等等。這類的收口方式一般要在企業(yè)內(nèi)部統(tǒng)一建立一個共享的云化的中間件資源池。對此，這里的原則是：你要選擇容易進行業(yè)務(wù)邏輯和控制邏輯分離的技術(shù)。這里，Java 的 JVM+字節(jié)碼注入+AOP 式的Spring 開發(fā)框架，會帶給你太多的優(yōu)勢。你要選擇可以享受“前人種樹，后人乘涼”的有技術(shù)紅利的技術(shù)。如：有龐大社區(qū)而且相互兼容的技術(shù)，如：Java, Docker, ?Ansible，HTTP，Telegraf/Collectd……中間件你要使用可以 支持HA集群和多租戶的技術(shù)。這里基本上所有的主流中間件都會支持 HA 集群方式的。原則八：不要遷就老舊系統(tǒng)的技術(shù)債務(wù)我發(fā)現(xiàn)很多公司都很非常大的技術(shù)債務(wù)，這些債務(wù)具體表現(xiàn)如下：使用老舊的技術(shù)。比如，使用HTTP1.0， Java 1.6，Websphere，ESB，基于 socket的通訊協(xié)議，過時的模型……等等不合理的設(shè)計。比如，在 gateway 中寫大量的業(yè)務(wù)邏輯，單體架構(gòu)，數(shù)據(jù)和業(yè)務(wù)邏輯深度耦合，錯誤的系統(tǒng)架構(gòu)（把緩存當數(shù)據(jù)庫，用消息隊列同步數(shù)據(jù)）……等等?缺少配套設(shè)施。比如，沒有自動化測試，沒有好的軟件文檔，沒有質(zhì)量好的代碼，沒有標準和規(guī)范……等等來找我尋求技術(shù)幫助的人都有各種各樣的問題。我都會對他們苦口婆心地說同樣的一句話——“如果你是來找我 case-by-case 解決問題，我興趣不大，因為，你們千萬不要寄希望能夠很簡單的把一輛夏利車改成一輛法拉利跑車，或是把一棟地基沒打好的歪樓搞正。以前欠下的技術(shù)債，都得要還，沒打好的地基要重新打，沒建配套設(shè)施都要建。這些基礎(chǔ)設(shè)施如果不按照正確科學的方式建立的話，你是不可能有一個好的的系統(tǒng)，我也沒辦法幫你 case-by-case 的解決問題……”，一開始，他們都會對我說，沒問題，我們就是要還債，但是，最后發(fā)現(xiàn)要還的債真多，有點承受不了，就開始現(xiàn)原形了。他們開始為自己的“欠的技術(shù)債”找各種合理化的理由——給你解釋各種各樣的歷史原因和不得以而為之的理由。談著談著，讓我有一種感覺——他們希望得到一種什么都不改什么都不付出的方式就可以進步的心態(tài)，他們寧可讓新的技術(shù) low 下來遷就于這些技術(shù)債，把新的技術(shù)濫用地亂七八糟的。有一個公司，他們的系統(tǒng)架構(gòu)和技術(shù)選型基本都搞錯了，使用錯誤的模型構(gòu)建系統(tǒng)，導(dǎo)致整個系統(tǒng)的性能非常之差，也才幾千萬條數(shù)據(jù)，但他們想的不是還債，不是把地基和配套設(shè)施建好，而且要把樓修的更高，上更多的系統(tǒng)——他們覺得現(xiàn)有的系統(tǒng)挺好，性能問題的原因是他們沒一個大數(shù)據(jù)平臺，所以要建大數(shù)據(jù)平臺……我見過很多很多公司，包括大如 BAT 這樣的公司，都會在原來的技術(shù)債上進行更多的建設(shè)，然后，技術(shù)債越來越大，利息越來越大，最終成為一個高利貸，再也還不了（我在《開發(fā)團隊的效率》一文中講過一個 WatchDog 的架構(gòu)模式，一個系統(tǒng)爛了，不是去改這個系統(tǒng)，而是在旁邊建一個系統(tǒng)來看著它，我很難理解為什么會有這樣的邏輯，也許是為了要解決更多的就業(yè)……）這里有幾個原則和方法我是非常堅持的，分享給大家：與其花大力氣遷就技術(shù)債務(wù)，不如直接還技術(shù)債。是所謂的長痛不如短痛。建設(shè)沒有技術(shù)債的“新城區(qū)”，并通過“防腐層?”的架構(gòu)模型，不要讓技術(shù)債侵入“新城區(qū)”。原則九：不要依賴自己的經(jīng)驗，要依賴于數(shù)據(jù)和學習有好些人來找我跟我說他們的技術(shù)問題，然后希望我能夠給他們一個答案。我說，我需要了解一下你現(xiàn)有系統(tǒng)的情況，也就是需要先做個診斷，我只有得到這些數(shù)據(jù)后，我才可能明白真正的原因是什么 ，我才可能給你做出一個比較好的技術(shù)方案。我個人覺得這是一種對對方負責的方法，因為技術(shù)手段太多了，所有的技術(shù)手段都有適應(yīng)的場景，并且有各種 trade-off，所以，只有調(diào)研完后才能做出決定。這跟醫(yī)生看病是一樣的，確診病因不能靠經(jīng)驗，還是要靠診斷數(shù)據(jù)。在科學面前，所有的經(jīng)驗都是靠不住的……另外，如果有一天你在做技術(shù)決定的時候，開始憑自己以往的經(jīng)驗，那么你就已經(jīng)不可能再成長了。人都是不可能通過不斷重復(fù)過去而進步的，人的進步從來都是通過學習自己不知道的東西。所以，千萬不要依賴于自己的經(jīng)驗做決定。做任何決定之前，最好花上一點時間，上網(wǎng)查一下相關(guān)的資料，技術(shù)博客，文章，論文等 ，同時，也看看各各公司，或是各個開源軟件他們是怎么做的？然后，比較多種方案的 Pros/Cons，最終形成自己的決定，這樣，才可能做出一個更好的決定。原則十：千萬要小心 X - Y ?問題，要追問最初的原因?qū)τ赬-Y 問題，也就是說，用戶為了解決 X問題，他覺得用 Y 可以解，于是問我 Y 怎么搞，結(jié)果搞到最后，發(fā)現(xiàn)原來要解決的 X 問題，這個時候最好的解決方案不是 Y，而是 Z。這種 X-Y 問題真是相當之多，見的太多太多了。所以，每次用戶來找我的時候，我都要不斷地追問什么是 X 問題。比如，好些用戶都會來問我他們要一個大數(shù)據(jù)流式處理，結(jié)果追問具體要解決什么樣的問題時，才發(fā)現(xiàn)他們的問題是因為服務(wù)中有大量的狀態(tài)，需要把相同用戶的數(shù)據(jù)請求放在同一個服務(wù)上處理，而且設(shè)計上導(dǎo)致一個慢請拖慢整個應(yīng)用服務(wù)。最終就是做一下性能調(diào)優(yōu)就好了，根本沒有必要上什么大數(shù)據(jù)的流式處理。我很喜歡追問為什么 ，這種追問，會讓客戶也跟著來一起重新思考。比如，有個客戶來找我評估的一個技術(shù)架構(gòu)的決定，從理論上來說，好像這個架構(gòu)在用戶的這個場景下非常不錯。但是，這個場景和這個架構(gòu)是我職業(yè)生涯從來沒有見過的。于是，我開始追問這個為什么會是這么一個場景？當我追問的時候，我發(fā)現(xiàn)用戶都感到這個場景的各種不合理。最后引起了大家非常深刻的研論，最終用戶把那個場景修正后，而架構(gòu)就突然就變成了一個常見且成熟的的模型……原則十一：激進勝于保守，創(chuàng)新與實用并不沖突我對技術(shù)的態(tài)度是比較激進的，但是，所謂的激進并不是瞎搞，也不是見新技術(shù)就上，而是積極擁抱會改變未來的新技術(shù)，如：Docker/Go，我就非常快地跟進，但是像區(qū)塊鏈或是 Rust 這樣的，我就不是很積極。因為，其并沒有命中我認為的技術(shù)趨勢的幾個特征（參看《Go,Docker 和新技術(shù)?》）。當然，我也不是不喜歡的就不學了，我對區(qū)塊鏈和 Rust 我一樣學習，我也知道這些技術(shù)的優(yōu)勢，但我不會大規(guī)模使用它們。另外，我也尊重保守的決定，這里面沒有對和錯。但是，我個人覺得對技術(shù)激進的態(tài)度比起保守來說有太多的好處了。一方面來說，對于用戶來說，很大程度上來說，新技術(shù)通常都表面有很好的競爭力，而且我見太多這樣成功的公司都在積極擁抱新的技術(shù)的，而保守的通常來說都越來越不好。有一些人會跟我說，我們是實用主義，我們不需要創(chuàng)新，能解決當下的問題就好，所以，我們不需要新技術(shù)，更有的技術(shù)用好就行了。這類的公司，他們的技術(shù)設(shè)計第一天就在負債，雖然可以解決當下問題，但是馬上就會出現(xiàn)新的問題，然后他們會疲于解決各種問題。最后呢，最后還是會走到新的技術(shù)上。這里的邏輯很簡單 ——進步永遠來自于探索，探索是要付出代價的，但是收益更大。對我而言，不敢冒險才是最大的冒險，不敢犯錯才是最大的錯誤，害怕失去會讓你失去的更多……（全文完）

- END -

---

看完一鍵三連在看，轉(zhuǎn)發(fā)，點贊

是對文章最大的贊賞，極客重生感謝你

推薦閱讀

在鵝廠做了14年開發(fā)

如何掌握和精通一門技術(shù)

計算機專業(yè)有什么血淚建議嗎？

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 求點贊，在看，分享三連

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的强烈推荐|我做系统架构的一些原则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。