download:移動端架構師_Android架構師成長體系課程

 

 移動端架構師

移動端普通工程師到架構師的全方位蛻變
全面掌握面向移動端未來的主流技術棧
從零開始親自構建千萬級電商專案，串聯移動架構師成長各階段

 

 

什麼是架構師？

 

當我想回答這個問題的時分，一時刻卻發現不知道講給誰聽。
什麼是架構師，架構師要做什麼工作，為什麼Java的範疇裡，會更重視架構師？

很早很早之前，我關於架構的概念一點都不瞭解，依稀記得，架構（ architecture）這個詞，來自於修建範疇。
這關於我這個沒寫過幾行程式碼的人來說，瞬間就有了一種“不明覺厲”的崇拜感。
架構，感覺好厲害的姿態，從名稱上來說，好像是規劃根骨，規劃底層，規劃最中心的東西的人。
架構師，必定很NB，我什麼時分能成為架構師呢？

後來懂了一點點程式碼，去寫增刪改查，更是體會不出來架構的概念，不便是Sql句子嗎？明明DBA更厲害啊，做各種的慢Sql優化，悉數的Sql都要讓DBA審閱，DBA關於Mysql，或者是Oracle的各種功能調憂很厲害，而瞭解事務的開發人員又常常能寫出幾萬行的SQL句子。
我看到這些頭都要炸了好麼？

所以，倒底什麼是架構？整個體系只有一個WEB，Spring MVC+Spring+Hibernate搞定悉數，開端做需求分析，實際上便是規劃表結構而已，剩下的便是查查查，改改改，刪刪刪。
直到某天，我知道一個詞，快取。
快取這玩意兒，在很早之前學習各種基礎課程的時分，瞭解過一些，一級快取，二級快取什麼的，LRU我好像也懂一點點，可是，在體系裡，快取算是什麼？
在公司裡，那個架構師，畫了一張圖，告訴我們，這臺機器上，放了一個Memcache，然而我們都不明白，他只解說了一句，這個Memcache是快取。
我的第一個困惑便是，悉數的懇求都要再次轉發到另一臺機器上，把資料取出來，單個懇求或許不算什麼，每天有幾十萬次懇求，這中心的損耗不大麼，為什麼不把Memcache放到本地機器上呢？
他沒解說，只告訴我說，不大，Memcache便是要放在另一臺機器。
在其時，我不清楚內網和外網的不同，也不清楚拜訪Memcache的懇求倒底是需求多少MS，更不瞭解，把Memcache放在和事務層一臺機器，或者是分開放的不同倒底是什麼。
但這個問題一向困惑著我，簡略來說，這其實算是一點點架構師要做的工作的萌芽，一個體系中，假如拆解出來了許多模組，倒底應該部署在哪些機器上？架構師會處理這些問題。

後來，到了搜狐之後，我突然間發現了我之前學到的東西，在搜狐的技能大神面前，直接被轟成渣。
負載均衡是什麼？熱備又是什麼？
穿透DB是什麼意思？怎樣我取資料庫裡取一個值，資料庫裡沒有，這種空資料的懇求會把DB打跨？我還要把這些為Null的懇求獨自快取起來？
本地快取做為一級快取，Memcache做二級快取？
“對快取來說，最要害的規劃就在於失效策略是什麼。”大神鎮定的看著我。
我很惶恐，感覺能把失效策略規劃出來，很不容易。
不同的運用場景，關於快取的要求不相同，對實時性的要求也不相同。榜單這種一天更新一次的，每天晚上守時生成一次就好了。後臺更新，可是要注意，必定要直接生成，直接切換，不能讓前端使用者拜訪的時分，再去生成。
關於名字這種東西，使用者改完之後，有必要立刻更新快取，包含本地快取和長途快取。
這算不算架構中的一部分，根據不同的運用需求，去規劃不同的策略，同時把這些場景規範化，成為一整個團隊都要去遵從的標準？
我不知道，我只知道，能Hold住團隊裡悉數人的那個人，技能必定十分NB，團隊裡的每一個人，都會質疑，假如你Hold不住全場，怎樣能推廣下去？
其時近30的技能團隊裡，每一個都是神相同的存在啊，誰能Hold住30多個神。
並且，本來不該該把悉數的程式碼放到一個WEB裡，本來分散式是這麼回事兒，本來一個體系，是由多個子體系構成的，本來還要分層，本來封裝和籠統是這麼個意思。
WEB層是一層，通常可以通過LVS部署兩臺到三臺，或者是更多的，Service一層用來處理事務邏輯，快取層用來扛併發，必定要藏在Service裡面，Controller呼叫Service的時分，並不需求知道，資料倒底從哪來的，每一個Service運用什麼樣的快取策略，徹底不需求Controller層知道，耐久化，對，關於大型運用來講，Mysql只能用做是耐久化，Mysql的單條拜訪速度並不查，只是在併發才能太差，扛不住。可是，有或許資料量過億啊？
過億怎樣辦？是用分庫，仍是分表？讀寫分離要不要做？一臺服務掛一臺資料庫，哪些資料庫應該放在一個例項裡，哪些應該獨自拆出去？每臺伺服器的配置是什麼？
我大概知道一點點，架構師要做哪些工作，他便是要把這些大的骨架定好，然後我們去填充裡面的內容。假如骨架定歪了，其餘團隊必定跟著歪。

這時分有了一系列的問題，第一個，Controller和Service之間，Service和Service之間，應該通過什麼呼叫？
RMI，這是專一的挑選。用thrift，或者是ProtocolBuffer，或者是Rest完成的RPC？
這是架構師要考慮的工作，假如是用RMI，我們是要自己完成，仍是要找找是否有好用的開源的結構，在其他的體系裡被證明了是有用的？
大神們花了兩週的時刻，對其時盛行的開源結構過了一遍，終究選定了Tuscany，到現在我都覺得規劃精巧，完暴Dubbo的東西，真的是一點都不想切到Dubbo上去，畢竟“曾經滄海難為水，除卻巫山不是雲”。
直到最近幾年微服務鼓起的時分，我仍是相同的呆若木雞，這跟2009年搜狐其時做白社會的架構比起來，優勢倒底在哪裡？不同好像沒有那麼大啊，並且Tuscany完成的更完美，只是運用的時分要有更強的約束，由於Tuscany太強大了~強大到有一點點重，有必要要做簡化，並且，Tuscany的開發團隊不怎樣維護了，白社會其時做的東西，仍是大神花了兩週的業餘時刻寫了一個Scallop，增加了Tuscany的負載均衡的功能。
可是，倒底用什麼，不用什麼呢？除了Tuscany，還討論過要不要用Hadoop，要不要用ActiveMQ，要不要用Erlang。
每一個技能結構的挑選，都通過討論，驗證，測試，終究在全團隊裡推廣。

這是否也是架構師的職責？這個架構師太厲害了，他需求從前到後都要懂，他需求擬定要害的技能細節，他需求給出最佳實踐，他需求瞭解業界悉數盛行的處理計劃，他需求去猜測Facebook怎樣處理問題的，Twitter怎樣處理問題的，Google怎樣處理問題的，這些處理計劃可不可以拿過來，也相同適用於我們自己的場景。
他需求通曉分散式，Nginx或者是F5，微服務，快取，耐久化，音訊佇列，他需求瞭解悉數這些技能細節裡的最常用的處理計劃，不能有遺漏，也不可以過度規劃，他決定的不是他一個人喜歡的風格，他決定的便是整個團隊，在專案死亡之前都有必要遵從的規範，現在的團隊成員，和未來的團隊成員，都有必要遵從的體系，並且，假如在未來，這些架構體系有不合理的地方，那就麻煩大了。
這樣的架構師，還要肩負著一個重大的任務，修復開源軟體的Bug。
在很早之前，我一向誤認為開源軟體是很厲害的很NB的東西，我一向認為這是完美的，很久很久之後，才明白，所謂的完美，都是用血和淚塑造而來的。
不通過各種各樣的驗證，環境，運用的測試，很難到達一個上線標準的穩定，即便是上線了，也有或許會出現之前徹底預料不到的問題。
可是，假如你挑選了這個結構，出了問題，誰去處理？
架構師，他要開原始碼，瞭解這些開源結構的思路，然後去找有或許產生問題的地方，再去修復他。
我一向都覺得，能看懂他人寫的程式碼的人，都是神。
某段時刻我去看一個heritrix,看的我神清氣爽，各種層出不窮的繼承，各種籠統類，連著三天我欲仙欲死，愈加堅決了我死也不要，也不允許其他人在專案裡運用繼承的決計。
可是Heritrix從表面看起來特別牛，他的抓取策略也很NB，用的分散式抓取的處理計劃十分輕巧。可是我我實在是不想再去讀一次了，在其時不讀不行，資料太少。
那麼，一個架構師，要對這些原始碼都瞭解麼？又或者是，他有必要具備，需求他去讀原始碼，他就有必要讀原始碼，並且去優化的才能？這大概比提早懂原始碼，更神奇。
由於是有時刻要求的啊，簡略來講，他需求在一個有用的時刻內，去弄懂悉數的底層的東西，說句實在話，當有同事嘲笑我都沒有完整的看過TCP/IP協議詳解的時分，我真的是無話可說的。
關於特別底層的東西，我的確瞭解的不夠多，可是架構師們不相同。
有了這些，就可以稱之為架構師了麼？
架構師需求懂事務麼？是不是就可以每天看技能，寫底層結構（比如我們本來在搜狐用到的DAL，資料拜訪層，用起來簡直是神器的東西）。

沒有不明白事務的架構師，悉數的架構，都依賴於事務。悉數的架構師，也有必要要去寫事務程式碼，不把自己規劃的東西，用在真實的專案裡，恐怕他們自己都不會知道，這種架構規劃的合理性在哪裡。
在某團購公司上市之前，他們的CTO拿出來了他們的架構圖給我看，在給我看之前，悉數的技能術語都相同，可是當我認真看了架構圖之後，我的困惑。。。。

為什麼Memcache要放在Controller層被呼叫？ 不該該是放到Service層嗎？
怎樣會出現你說的，一個Serivce負責維護的資料，也有或許被別的的Service去更改的狀況？每一個Service對資料的操作，有必要是獨立的啊，除了這個Service，其他的任何服務都決不允許直接更改DB啊。
並且，怎樣Service拆分了，DB不拆分呢？這樣的話，壓力大的DB會把全站拖跨的啊。
那張架構圖我看到之後，感覺自己的認知被突破了，本來可以這麼做，本來相同的，相似的技能選型，可以做出來如此艱難的東西？
就在我認為這其實就差不多是架構師的悉數的時分。
在最近一段時刻，我突然間發現了一個問題。
為什麼有的人程式碼寫的這麼爛，許多寫死的程式碼，一點兒靈活性都沒有，更沒有規範，徹底便是堆壓。
為什麼有的人底子不知道怎樣去籠統，並不清楚怎樣樣積累成公共元件，為什麼他們改一個問題，通常會引出更多的問題？
為什麼他們的程式碼裡的完成計劃，讓人看完之後恨的牙癢癢，想改又徹底不能改，畢竟，正常工作的程式碼才是好程式碼？
很大程度上是由於，許多程式設計師，不明白的程式碼的擴充套件性，不會面向未來程式設計。
怎樣叫做面向未來程式設計？
一個好的工程師，在聽到需求的時分，可以根據自己的事務才能，判斷出來這些需求中，哪些是有或許改變的，哪些是不太或許改變的。
針對這些改變的內容，在編寫的過程中，不會寫死，而重複承認不或許會改變的需求，會寫的簡略一些，避免過度規劃引起的複雜度。

簡略說，當他拿到需求時，並不單純是考慮這個需求怎樣完成，還會考慮，自己規劃的架構體系，擴充套件性在哪裡，在他的眼裡，看到的需求會被分解，折分，然後自己的技能計劃，會挨個分解，分配。
在完成規劃之後，他會很清楚的知道 ，自己規劃的體系裡，哪些改變是支撐的，隨便你改，我只需求改動一個很簡略的內容，哪些是你肯定不能改的，你要改，我就有必要花很大的代價，特別是在已經有線上資料的時分。

並且會拿著自己的架構體系跟PM交流，講清楚。
什麼樣的改變是支撐的？簡訊通道是有或許改變的，而呼叫簡訊通道的地方或許會有點多，所以我有必要把簡訊通道籠統，並封裝在一個公共介面，假如需求替換簡訊通道，我或許只需求更改一個配置檔案就好了。

那麼什麼樣的改變是不支撐的？我不需求不停機就替換簡訊通道的功能，除非你在後臺體系中提早配置好，或者是有明確的需求，我做出這麼一個東西出來。往往在前期，不會用到。
為什麼？
在創業初期，簡訊通道往往用於使用者註冊，一旦出問題，便是生死問題，有必要要有一個備份，運營商一怒封掉你的通道，很常見。
而重啟一次服務，在創業前期，往往沒有那麼嚴峻。
所以，這些技能，是不是也應該歸納到架構師的職責裡去？
架構師從開端就要考慮選型，從言語開端，從事務開端，要對這個範疇裡的開源結構瞭解，瞭解，要能處理疑難問題，要懂安全，要會備份，要學會面向未來程式設計，還需求什麼？

還需求DevOPS.
在繼續整合的時代，在伺服器規模越來越大，在雲伺服器的時代，在異地儲存，冗災，在全球化越來越快的時代。
運維的重要性已經到了一個很中心的程度了。彈性伸縮，自動擴容，灰度釋出等等等概念，要求，都在衝擊著架構師這個概念的定義。
假如說之前的架構師，更多的是在體系開發前，現在越來越偏於體系上線後。
還包含資料分析，日誌分析，等等等等，對了，還沒有說到Nosql DB，實時查詢，知識庫，演算法這一系列的東西。
每一個範疇都在細分，每一個概念都在深化。
簡略說，架構師的確和言語無關，可是又肯定和言語有聯絡。
你可以說，架構師便是在做選型，可是隻會做選型，肯定做不出架構師。
Java更需求架構師，由於他本身便是各種開源結構，不對這些結構瞭解的清清楚楚，你很難做出一個好的挑選，而一旦架構被固定，實際事務人員的開發，又會變的簡略許多。
說到了現在，我有沒有講清楚架構師是什麼？
而你，還想要做架構師嗎。

反正，我說自己是架構師的時分，我的內心是羞恥的，我知道 ，我遠遠沒到達架構師的才能。