1.架構師應不應該寫代碼

　　合格的程序員對于明確分配的任務會完成的很好，但是大部分情況下“架構”這個詞意味著架構師并不會涉及太多細節，架構圖和代碼實現之間總還是有些距離，你無法保證所有人都會正確的理解你的設計，或者是程序員寫代碼時遇到障礙時會立刻想出足夠優雅的解決方案。

　　在我看來，寫代碼的架構師更像是在做后勤保障的工作：在代碼中第一時間發現可能存在的問題，向其他人提出警告，或是給予其他人改進的意見，必要的時候或是給其他人演示一下正確的姿勢。

　　大部分情況下我作為架構師并不需要攬下“核心模塊”開發這種工作，畢竟我能調配的時間太零散了，效率難以保證，很多人在專注的情況下比我做的好很多，我只需要保持大局觀需要適度參與就可以了。

　　總的來說，架構師和程序員在某些方面上有點像產品經理和用戶的關系，大部分程序員并不會主動告訴你他們想要什么、哪里需要優化，甚至自己也不知道這些。想要做出好的產品，捷徑之一就是跟用戶做同樣的事情。

　　2.為什么別人的系統總是那么爛

　　很多程序員解決問題的能力很強，說要解決一個什么問題，下午就能寫出幾百行代碼把功能實現了。但是做出來的東西有種少考慮了什么東西的感覺。大部分程序都能實現功能，但是如果把“時間”這個也作為一個考慮的維度的話，就會意識到一個合格的項目需要考慮更多的東西：更通用的使用方式、易于理解的文檔、簡單而易于擴展的設計，等等。

　　很多公司應該都會有一些遺留系統，它們龐大、笨重、難用、幾乎無法維護，所有人都在抱怨這些系統，并且每天都在想方設法換掉那些遺留系統。但是一段時間過去之后，又會發現身邊的新人又開始吐槽當時替代遺留系統的那個系統了。

　　“大多數系統當初都很好使，功能當時夠用，擴展性看起來也可以，但是這些系統都是開發的人離職之后變壞的。”

　　3.成為架構師最困難的門檻是什么？

　　很多人自稱架構師的人跟你講一個架構時簡直滔滔不絕，各種技術名詞像是說相聲一樣從他嘴里說出來，三句話不離高并發大數據，但是稍微追問一下，就會發現很多基本概念的缺失，例如自稱精通高并發的人說不清楚他所謂的高并發系統的瓶頸在哪里，自稱精通架構設計的人說不明白他的系統怎么保證高可用，自稱超大數據量的系統實際上只有不到100萬條數據，等等。

　　架構師雖然聽起來很高大上，但本質上仍然是工程師，不是科學家，也不是忽悠人的江湖騙子。學習再多，也需要實踐落地。設計架構方案更多的是在做一些抽象和權衡：把復雜的需求抽象成簡單的模型，從功能、性能、可用性、研發成本等等方面規劃如何構建一個系統，這些內容需要更多的實踐練習。

　　4.如何更高效的學習？

　　大多數人每天能留給自己學習的時間有限，這個階段如何提升學習效率就成了要解決的重點。

　　說說自己提升學習效率的心得，其實非常簡單：體系化的學習。

　　在重復了幾次痛苦的學習-梳理過程后，再去看一些獨立的文章或者資料往往會事半功倍，因為能在體系內找到相對應的知識，甚至有時候一本書里一頁只需要看一句話，點破那層窗戶紙，就可以掌握新的知識。

　　跟很多人一樣，剛畢業時我覺得作為程序員，只要努力，加上少許天賦便可以獲得一些成績。

　　工作一段時間后，對自己和其他人的認識也越來越清晰，逐漸的發現程序員之間的差距或許比人和猴子之間的差距還大，接受這個事實這讓我郁悶了很久。

　　再過一段時間，發現自己已經能夠客觀的評價自己的能力，也意識到了距離并不是那么重要，只要想辦法跑的更快，就足夠了。

      分布式架構體系

　　分布式怎么來的。傳統的電信、銀行業，當業務量大了之后，普通服務器CPU/IO/網絡到了100%，請求太慢怎么辦？最直接的做法，升級硬件，反正也不缺錢，IBM小型機，大型機，采購了堆硬件。

　　但是互聯網不能這么干，互聯網沒有那么財大氣粗，還有很多初創，能不能賺錢還不知道。所以就有了軟件方面的解決方案：分布式系統，簡單說，就是一臺服務器不行，我用兩臺、10臺、100臺...這就要軟件系統需要支持。

　　那么多臺機器，我如何讓他們協同工作，這就需要一個調度中心（或注冊中心）；肯定涉及到機器間通信，那么需要一個高效的RPC框架；一個請求過來了，如何分發，需要一個請求分發系統（負載均衡）；然后還要考慮每個角色都不能成為性能瓶頸；還有要能方便的進行橫向擴展，還有考慮單節點故障。

　　并發編程體系

　　為什么需要并發

　　并發其實是一種解耦合的策略，它幫助我們把做什么（目標）和什么時候做（時機）分開。這樣做可以明顯改進應用程序的吞吐量（獲得更多的CPU調度時間）和結構（程序有多個部分在協同工作）。做過JavaWeb開發的人都知道，JavaWeb中的Servlet程序在Servlet容器的支持下采用單實例多線程的工作模式，Servlet容器為你處理了并發問題。

　　誤解和正解

　　最常見的對并發編程的誤解有以下這些：

　　-并發總能改進性能（并發在CPU有很多空閑時間時能明顯改進程序的性能，但當線程數量較多的時候，線程間頻繁的調度切換反而會讓系統的性能下降）-編寫并發程序無需修改原有的設計（目的與時機的解耦往往會對系統結構產生巨大的影響）-在使用Web或EJB容器時不用關注并發問題（只有了解了容器在做什么，才能更好的使用容器）

　　下面的這些說法才是對并發客觀的認識：

　　-編寫并發程序會在代碼上增加額外的開銷-正確的并發是非常復雜的，即使對于很簡單的問題-并發中的缺陷因為不易重現也不容易被發現-并發往往需要對設計策略從根本上進行修改

　　性能優化

　　性能優化，簡而言之，就是在不影響系統運行正確性的前提下，使之運行地更快，完成特定功能所需的時間更短。性能問題永遠是永恒的主題之一，而優化則更需要技巧。

　　工程化專題

　　工欲善其事必先利其器，工具對Java程序員的重要性不言而喻現在有很多庫、實用工具和程序任Java開發人員選擇。下圖列出的工具都是程序員必不可少的工具

　　微服務架構

　　微服務（Microservice）這個概念是2012年出現的，作為加快Web和移動應用程序開發進程的一種方法，2014年開始受到各方的關注，而2015年，可以說是微服務的元年；

　　越來越多的論壇、社區、blog以及互聯網行業巨頭開始對微服務進行討論、實踐，可以說這樣更近一步推動了微服務的發展和創新。

　　微服務架構（MicroserviceArchitecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的

　　類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，并提供更加靈活的服務支持。

　　項目實戰專題

　　對于所學的知識將用一個大型的電商項目來實踐使用你的知識

       以上就是動力節點java學院小編針對“一位程序員的進階Java阿里學習路線”的內容進行的回答，希望對大家有所幫助，如果對于學習Java的學習計劃，怎么學才有效率，或者學完如果找工作的問題，請在線咨詢，有專業老師隨時為你服務。