掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
現代API: 通往架構師之門 版權信息
- ISBN：9787302505693
- 條形碼：9787302505693 ; 978-7-302-50569-3
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
現代API: 通往架構師之門 本書特色
匯集20年系統集成和API項目實戰經驗，軟件開發人員成為架構師的必讀指南
現代API: 通往架構師之門 內容簡介
本書首先回顧系統集成及服務的歷史，對其核心概念和核心思想進行重新闡述；然后從基本概念、REST架構、生命周期、具體實施、很好實踐、業務影響和技術前瞻等方面對API進行多方面的介紹；很后是作者對如何做一個好的架構師的感悟與建議。貫穿全書的是作者在近20年里，為北美18個行業里的50多家大型公司進行系統集成及API項目設計和實施積累下來的實戰案例。 本書為有志于成為系統集成和API架構師的程序員提供了一條學習和提高的路線圖，適合程序開發人員及管理人員閱讀和參考。
現代API: 通往架構師之門 目錄
第1章概述
1.1什么是架構和架構師
1.2這本書是為誰寫的
1.3為什么寫作此書
1.4通往架構師之路的路線圖
1.5架構師應該具備的素質
1.6對架構師的學習和培養過程的幾點建議
1.7本書的主要內容
1.8總結
第1部分基礎篇
第2章重新看待系統集成
2.1系統集成歷史的快速回放
2.2到底什么是系統集成
2.2.1系統集成之信息更新
2.2.2系統集成之信息組合
2.2.3系統集成之連鎖行動
2.3系統集成的技術組成部分
2.3.1BUS——高速公路
2.3.2連接器——高速公路的進出口
2.3.3CDM——高速公路運輸的集裝箱
2.3.4數據轉換——運輸過程中的貨物處理
2.4系統集成應用的考慮
2.4.1系統集成的過程中到底要完成什么任務
2.4.2如何保證系統集成過程中數據傳遞的可靠性
2.4.3如何使用消息服務器
2.5實戰： PLM數據與現有系統的集成
2.5.1項目背景
2.5.2業務痛點
2.5.3技術難點
2.5.4解決方案及經驗教訓
2.6總結
第3章系統之間相互作用的模式
3.1系統集成模式簡介
3.2系統集成模式中幾個*重要的概念
3.2.1主題與隊列在消息傳遞中的區別
3.2.2消息服務器所使用的儲存轉送
3.2.3消息服務器的容錯和高可用性
3.2.4分級式事件驅動架構及其實際應用
3.3系統集成模式的實戰應用和分析
3.3.1消息的順序處理
3.3.2持久訂閱如何實現
3.3.3命令類消息的應用
3.3.4事件消息的使用
3.3.5回復地址的使用
3.3.6消息傳遞搭橋的使用
3.3.7消息信封的使用
3.4總結
第4章常見的參與集成的功能系統
4.1功能系統與集成基礎設施的連接
4.2常見功能系統的功能和類型
4.3總結
第5章究竟什么是服務
5.1什么是服務
5.2是誰在推動服務的重復使用
5.3服務的操作
5.4服務的界面
5.5服務操作的粒度
5.6服務的組合——SOA
5.7實戰： 數據
5.7.1項目背景
5.7.2業務痛點
5.7.3技術難點
5.7.4解決方案及經驗教訓
5.8總結
第6章系統集成項目的實施步驟
6.1系統集成與服務項目概述
6.2系統集成與服務項目的具體實施步驟
6.3設計和開發階段
6.3.1搜集項目業務功能要求
6.3.2架構設計
6.3.3細節設計
6.3.4代碼編寫和單元測試
6.3.5集成測試
6.4測試和驗收階段
6.4.1質量保證(QA)部署
6.4.2質量保證(QA)測試
6.4.3用戶驗收(UA)部署
6.4.4用戶驗收測試(UAT)
6.4.5(可選項)操作驗收測試(OAT)
6.5運維、培訓和交付階段
6.5.1生產環境部署
6.5.2試運行
6.5.3培訓及文檔提交
6.5.4項目驗收
6.6總結第7章集成項目與公共服務
7.1公共服務的具體內容
7.1.1日志服務
7.1.2出錯處理服務
7.1.3ID映射服務
7.1.4順序處理服務
7.1.5系統及應用監控服務
7.1.6應用、服務、API的分析服務
7.2業務項目的項目模板及其與公共服務的互動
7.3總結
第8章SOA在實施中的局限性
8.1SOA在具體實施中的做法
8.1.1SOA的設計原則
8.1.2SOA績優中心
8.2深挖SOA的初衷
8.3SOA的適用范圍和局限性
8.4總結
第2部分正篇——現代API、應用互聯網
第9章現代API的引入、應用互聯網
9.1什么是（現代）API
9.1.1REST架構的特點
9.1.2REST架構的特點在API中的具體應用
9.2（現代）API流行背后的原因
9.2.1API和云平臺的普及
9.2.2API與企業數字化轉型、應用互聯網以及API經濟
9.3API的平臺和工具有待進一步地統一和標準化
9.4一個REST API的結構
9.5對API的認識不是一蹴而就的
9.6動手開發API——先嘗為快
9.7總結第10章圍繞API的開發工作
10.1API的生命周期
10.1.1API的設計生命周期
10.1.2API的運維生命周期
10.2API的調用者
10.3API項目中的人員和流程
10.3.1什么是使能中心
10.3.2圍繞使能中心的不同角色
10.3.3使能中心與績優中心的區別
10.3.4建立使能中心的具體步驟
10.3.5建立使能中心的好處
10.4總結
第11章API與微服務
11.1什么是微服務
11.2微服務與服務的關系
11.3微服務與API的關系
11.4總結
第12章API與云計算
12.1云計算需求的由來
12.2云計算對API技術的影響
12.2.1云計算的平臺能為你的API和應用提供多少服務
12.2.2現有系統之間的連接是否受到影響
12.2.3是否需要增加安全措施
12.2.4如何將API負責對內和對外的部分分開
12.3實戰： 全云和云本地混合型的API平臺
12.3.1項目1背景
12.3.2項目1云平臺的架構
12.3.3項目2背景
12.3.4項目2混合型平臺的架構
12.4總結第13章*佳實踐的經驗
13.1關于系統集成的*佳實踐
13.1.1不要以“數據復制”的思考方式設計系統集成
13.1.2盡量避免使用批處理文件的方式
13.1.3對消息服務器運行的認識
13.1.4使用SEDA的架構模式來提高系統集成整體設計
的可靠性
13.1.5對容錯、負載平衡和高可用性的考慮
13.1.6對災難恢復設置的考慮
13.1.7接收JMS消息時的消息確認方式對消息處理
可靠性的影響
13.2關于API的*佳實踐
13.2.1在設計API的過程中使用“資源”的字眼，而不要
使用“數據”
13.2.2不要使用API的概念和方式來做系統集成
13.2.3API還是連接器
13.2.4API實施中的出錯處理
13.2.5API的URI的每一個部分都應該是名詞，
而不是動詞
13.2.6API的版本管理
13.3關于架構設計的*佳實踐
13.3.1不要使用UML的時序圖來編寫系統集成的
用例文件
13.3.2注意區分設計中功能方面和非功能方面的要求
13.3.3不要在沒有系統性能指標要求的情況下對系統
進行性能的評價和測試
13.3.4數據驗證邏輯與數據的關系
13.3.5API、服務和集成中均不保留狀態
13.4總結
第14章圍繞API的展望
14.1關于企業的IT欠債
14.2利用API產生新的業務——創新和數字化轉型
14.2.1優步（Uber）的創新
14.2.2郵局的數字化轉型
14.2.3電力公司旨在提高零售用電顧客滿意度
的數字化轉型
14.2.4玩具公司旨在減少貨運差錯和加快貨款回收
的數字化轉型
14.3利用API產生應用互聯網和API經濟
14.4總結
第3部分閑篇——感悟與隨想
第15章架構師的人文情懷
15.1關于學習過程中的三個境界
15.2架構師所要具備的硬實力
15.3架構師所要具備的軟實力
15.3.1時刻分清目的和手段
15.3.2處處講究形式邏輯
15.3.3強調利用抽象思維的能力
15.3.4表達和交流要看對象
15.3.5堅持原則，但也要知道妥協
15.3.6知之為知之，不知為不知
15.4架構師所處的大環境
15.4.1架構師的職業規劃
15.4.2軟件工程問題與業務問題的分離
15.4.3高校計算機軟件課程設置與現實對架構師要求的
匹配問題
15.5總結
附錄A關于實踐
A.1搭建MuleSoft的開發和運行環境——開源版
A.1.1開發環境
A.1.2運行環境
A.2安裝Apache ActiveMQ消息服務器——開源版附錄B集成中常遇到的功能系統
B.1業務流程管理系統（Business Process Management，BPM）
B.2復雜事件處理（CEP）
B.3云端系統
B.4客戶關系管理系統（CRM）
B.5數據庫系統（Relational、Object、NoSQL）
B.6電子內容管理（ECM）
B.7電子商務（eCommerce）
B.8電子數據交換（EDI）
B.9企業資源規劃（ERP）
B.10人力資本管理
B.11行業標準
B.12IT開發和運行工具
B.13IT基礎設施管理
B.14傳統系統改造
B.15主數據管理
B.16消息傳遞服務器
B.17通信協議
B.18社交媒體
展開全部
現代API: 通往架構師之門 節選
第1章概述 在軟件行業里,架構師們的頭上仿佛都帶有光環。他們往往對復雜的問題舉重若輕。幾乎每一個年輕的程序員都希望有朝一日自己也能成為一名經驗豐富的架構師,領導著一個開發團隊、解決著世界上*復雜的軟件架構設計和實施的問題。 然而,一名成功的架構師到底學習了哪些東西、又經歷了怎樣的歷練，似乎沒有人講解過；大學里從來不曾開設過相應的課程,更沒有人能夠提供一張“課程表”；市面上的關于架構的圖書大多或偏重于講授抽象的設計原則，或偏重于對設計思想的感悟。讀者如果沒有親身經歷過具體的項目案例，抽象的設計原則缺乏系統的應用指導和可執行性，而感悟只有在讀者親自做過之后才有可能產生共鳴。那些缺乏經驗的新人該怎么辦呢？他們是多么希望有一張通向架構師的路線圖啊！ 1.1什么是架構和架構師 萬事開頭難,文章開篇難！為了建立一個大家理解相同、不產生歧義的溝通基礎，我們必須從兩個*基本的概念入手。 首先，*重要的概念就是架構。按照維基百科的說法https：//en.wikipedia.org/wiki/Software_architecture： 軟件架構是指軟件系統在高層次上的結構、創建此類結構的指導原則，以及這些結構的相關文檔。這些結構可以用來推斷和評價待建的軟件系統。每一個結構包含軟件的組成部分及其相互之間的關系，以及組成部分和相互關系的屬性。一個軟件系統的架構類似于建筑的架構。其次，就是架構師的概念及分類。還是按照維基百科的說法https：//en.wikipedia.org/wiki/Software_architect： 軟件架構師的工作就是進行高層次上的設計方案選擇、制定相關的技術標準，包括軟件編碼標準，并確定所使用的軟件工具和平臺。盡管有人將架構師的種類分得很細https：//blog.prabasiva.com/2008/08/21/differenttypesofarchitects/，實際*常見的架構師分為兩種。〖=1〗 企業架構師（Enterprise Architect）： 研究的對象是解決方案架構師在實施工作過程中所使用的方法，為后者解決具體的業務問題提供架構設計以及實施的具體步驟和方法指導。 解決方案架構師（Solution Architect）： 實際承擔解決企業業務問題的任務。有可能需要使用企業架構師所提供的架構設計以及實施的具體步驟和方法指導。〖=2〗換句話說，企業架構師解決的是IT問題，而解決方案架構師解決的是業務問題。貫穿本書所指的架構師是后一種，即解決方案架構師。不僅如此，本書面向的是那些解決方案涉及多個功能系統的使用、架構原則和思想具有橫跨企業的指導意義的架構師。 1.2這本書是為誰寫的 本書針對的讀者群包括希望成為解決方案架構師的程序員、IT咨詢師，希望通過與同行進行交流而得到提高的架構師，還有希望了解如何能夠讓自己的部門有效地應對不斷變化的企業業務要求的各級IT 領導。 一名IT從業人員可能正處在下面列出的一種情形之中： 1) 剛剛走出大學的校門、參加工作。在計算機系里已經學會了一門或幾門編程語言（如Java、C#、Python，等等），以及數據結構和算法，對后臺數據庫、網站架構甚至SOAP Webservices都有初步的了解，并且可以很熟練地進行編程來解決別人交給的非常具體的問題。但是如果面對類似本章1.3節中所描述的那幾個實戰例子就不知從何下手了。 2) 從事軟件開發工作3～5年，十分勝任小型或局部問題的分析、方案設計和具體實施。然而面對規模稍大、更加復雜并涉及多個系統的業務問題的設計任務時會感到力不從心，不知道從何下手，不知道應該采用什么樣的原則以及設計和實施步驟，也不知道應該使用何種工具。 3) 作為一名具有2～3年實際經驗的架構師，已經參與和主持了幾個系統集成項目的設計和實施工作，但對為什么采用某個設計方案、其優點和缺點的評估卻說不出個所以然來，因此無法在下一個項目的工作中信心十足地再次采用類似的方案。 4) 從事架構師的工作已有5～10年，能夠深入了解具體設計方案背后的來龍去脈，以及設計方案的優點、缺點甚至相應的補救措施。然而，面對一個復雜項目各方面的利益相關人（如項目出資方、業務分析人員、其他設計人員、開發團隊、項目經理、合作伙伴，等等），深深地感到將項目設計的思想和方案優缺點論述清楚并得到方方面面的支持是一件十分困難的事情。即便是開發團隊內部的技術細節的溝通和統一也不是那么容易。 5) 作為一名具備多年實踐經驗的企業CIO，面對行業內競爭、行業外顛覆的壓力，以及企業業務對IT能力的要求與IT部門實際交付能力之間日益增大的差距（如圖11所示）深感憂慮（其背后的直接原因包括移動設備、云計算、社交網絡、大數據、物聯網等的廣泛和深入的使用），并苦苦探索可從IT技術和企業組織結構的不同角度對這個日益嚴重的問題做出有效的反應。 圖11數字時代的壓力造成了IT部門“欠債”越來越多 1.3為什么寫作此書 在從事軟件服務工作的近20年中，作者親身經歷了北美18個行業、50多個客戶的大型項目，其中還包括兩三個完全失敗的項目。客戶中的絕大多數是財富500強的公司，有些甚至是50強。 我們先來粗略地感受一下這些項目。〖=1〗 某跨國石油公司的能源交易部門于2002年希望建立一個全球范圍的能源產品 （包括石油、天然氣、電力、污染排放指標等）交易結算和風險評估平臺，能源產品可在全世界各地進行交易，而新的交易實時地與交易伙伴進行結算，本部門所持有的能源產品組合的細節及其系統風險被實時地更新。如果交易的一方或雙方隸屬于某個母公司，母公司本身所持有的能源產品組合的細節及其系統風險也被實時地更新，任何過度風險的情形都會被及時預警。 美國某著名的航空快遞公司在2005年尋找一個高效、耐用的消息（message）交換平臺，能夠每天交換86000萬條在郵件遞送過程中由每一個處理中心的進出掃描而產生的消息。而這些消息在全天的任何時間、在世界上的任何地方不斷地產生著。在此平臺上需要進一步構建供廣大消費者使用的郵件跟蹤服務。到2010年，這個平臺的消息總處理能力達到了每天50億條。而且以不同名稱獨立運營的同一個母公司下的所有分公司使用快遞服務的總量，以及使用的模式可以被累加出來，為下一年針對不同母公司的大客戶進行更好的服務定價提供可靠的基礎。 美國某知名零售連鎖店有800多家店面，銷售包括衣服、家電、日用品等在內的上萬種商品。每個星期，總店都會在不同的商品上推出各種不同的促銷折扣以及減價券，而有些時候這些促銷折扣和減價券的有效期只有某一天中的幾個小時。促銷折扣及減價券的推出上線必須經過特定權限的批準，在此過程中完全不允許出現停機現象。 美國某玩具公司擁有多個世界上*著名的玩具品牌。在2012年引入了產品生命周期管理PLM（Product Lifecycle Management）的軟件系統后，PLM成為玩具產品設計、制造、市場開發、銷售、服務等幾乎所有的企業職能部門共同需要的平臺。然而，由于歷史的原因，這些職能部門目前使用的外購和自己開發的應用系統超過了50個，加上這些職能部門分布在北美、歐洲、中國、東南亞等多個地區或國家，實際上根本不可能讓這些職能部門全面放棄已經使用了十幾年甚至幾十年的、他們所熟知的系統。然而，由于所有圍繞玩具產品的各類職能的數據已經全部轉移到PLM平臺上，如何在保證這些職能部門繼續使用現有系統的同時，能夠從新的PLM平臺上及時、有效地獲得不斷更新的相關數據？ 美國某著名的二手車銷售連鎖店在美國和加拿大擁有近千家店面，銷售經過重新認證的二手車。總店擁有自己的IT系統，而每一個分店除了可以調用總店的IT系統外，還有一套本地備份，以便本地系統在與總店IT系統失聯的情況下仍能應付日常工作。連鎖店在2010年面臨的挑戰之一就是，每當總店推出一個新的系統部署時，比如升級和更新，甚至僅僅只是網頁上的橫幅圖標按某個節日進行臨時的更換，如何能夠*有效地部署到所有近千個店面的本地IT系統中，同時了解哪些店面的部署出現了錯誤并進行妥善的處理。這是一個相當具有挑戰性的問題我們*終的多店面部署解決方案被稱為StoreinaBox。。〖=2〗仔細研究一下上面這幾個實戰案例，我們也許會在某個局部發現書本上學過的N層網站架構或者某個設計模式（Design Pattern），但組合起來造成的問題之復雜，是我們從前不可想象的。 環顧軟件以外的其他行業，對過去的相關案例進行深入的分析和總結，無論對個人還是團隊來說，都是非常有效的學習手段。在商學院、醫學院、法學院、軍事學院和體育學院的課程安排里，案例的分析是學習的內容和過程中*重要的、也是*引人入勝的部分。通過例子來學習、先模仿再深入理解是*有效的學習方法之一。在作者的軟件咨詢服務工作過程中，客戶*享受的部分就是“聽故事”，然而作者卻沒有在美國和中國任何一所高校的計算機系網站上公布的授課內容中找到軟件項目設計和實施的案例。 除技術因素外，作者在主持項目設計和實施的過程中，對如何與客戶、合作伙伴，以及自身領導的開發團隊成員進行架構設計指導思想的溝通與說服工作，也積累了相當的感悟。 以上兩點促使作者下定決心，拋磚引玉，力圖提供一條由程序員到架構師的路線圖，并結合實戰的架構設計案例來對抽象的設計原則進行展開說明，為希望成為架構師的程序員們的學習和實踐過程進行具體的指導。本書將采取理論闡述和動手開發相結合的方式，以保證學習和能力提高的質量。 1.4通往架構師之路的路線圖 針對上面列舉的通往架構師的道路上的不同階段，本書擬引入如下的路線圖。 1) 起始于相互獨立的系統，首先討論如何進行系統集成（第2章~第4章）。具體內容包括系統之間進行集成時常見的相互作用模式、被集成系統的功能分類，等等。這一部分的內容已有大量的書籍進行了各種深入的闡述。然而在實際項目中遇到的許多關于設計方案選擇的把握并未見有論述；對系統集成設計的體會和設計思想上的領悟也未見有太多公開的發表。因此，希望對系統集成和服務架構有一定經驗和體會的讀者也不要輕易跳過這幾章。作者真心地期待你使用前言末尾列出的電郵地址分享案例、體會和領悟，抒發情懷。 2) 在通過集成、系統與系統之間的連接初見成效之后，引入服務的概念（第5章），并對圍繞服務的項目實施具體工作內容進行了解（第6章、第7章）。服務概念的出現雖然已有至少15年的歷史，但在絕大多數實際的項目實施過程中服務常常淪為“點對點”實施的一種新的連接機制，而整個架構思想換湯不換藥。其結果是，根本性的技術問題依然存在，一個也沒有徹底解決。 3) 在積累了一定的系統集成和服務項目的經驗后，第8章承上啟下，以作者在近20年的實踐中對系統集成和服務的方法以及在技術層面和IT組織結構層面上的局限性的總結和思考，引入現代API的概念，并與圍繞服務和系統集成項目的實施進行對比，從而對*新的、圍繞API的架構理念有一個初步的認識。 4) 了解圍繞API進行解決方案開發工作的具體內容，并對具體實施方法背后的深層思想進行梳理（第9章、第10章）。不論采用什么樣的API的設計和開發工具，這個過程大致相同： 從API的提供方看，涉及API開發的生命周期中的各種活動；而從API的使用方看，則涉及如何發現并正確使用API。 5) 深入了解API與微服務（以及服務）之間的關系（第11章）。這個問題常常被客戶問到，并且具有理論和實踐上的重大意義。 6) 深入了解API的部署方式，特別是正在興起的云端部署方式（第12章）。云端部署為API以及集成應用的目標環境提供了一種新的選擇。API架構師的目標是采用完全不依賴于目標環境（比如本地/數據中心、云端的虛擬機、云端帶有負載平衡器、集群等相關設施的部署環境，以及以上各種類型的混合體，等等）的基礎代碼，而是通過因目標環境而不同的配置上的變化來實現不同環境下的部署。 7) 在上述學習和提高的過程中，不斷積累*佳實踐的經驗和教訓（第13章），了解新的架構思想對企業業務發展的影響（第14章），加深在這方面的認識。 如果要打個比方，上面提議的路線圖有點兒類似于一個從士兵到將軍的計劃。士兵的責任在于提高體能，掌握軍事技能和武器裝備;中層軍官的責任在于熟悉自己權限以內的兵力調動，指揮戰斗和局部的戰役；而高級將領的責任則在于熟知軍事服務于政治，時刻牢記進行戰爭的*終目的，有能力指揮各兵種及各級軍官并協調友軍進行大規模的立體作戰。 1.5架構師應該具備的素質 要想成為一名優秀的架構師，除了高超的計算機軟件專業方面的知識以外，還必須具備一定的“軟實力”。有些軟實力看似十分簡單和基本，但在具體的執行過程中常常被遺忘和忽略。而錯誤的發生往往就是因為人們忽略了*簡單明了的一些基本原則。〖=1〗 永遠把解決客戶的業務需求放在**位。IT技術是手段，不是目的。無論你掌握的IT技術有多先進、多“酷”，如果不能解決客戶具體的業務問題，你掌握的技術就會被客戶看成是一無是處。所以作者經常講的一句話就是，“架構師別太把自己當回事兒”。 超強的邏輯性。這其中既包括分析問題的數理邏輯能力，也包括在闡述論點和設計思路過程中的一致性、連貫性和洞察力。 永遠開放的頭腦。傾聽和認真分析各種意見，始終抱著一種將事情做到極致的決心。 廣泛的知識面，對IT技術和業務知識有著同樣濃厚的興趣。如果對所要解決的業務問題漠不關心，是不可能完善地使問題得到解決的。 超強的學習能力，并學以致用。學習的內容包括IT技術、業務知識、管理知識、認知科學甚至心理學等人文方面的知識。 注重結果。無論開始和過程有多么華麗，只有結果的輝煌才是真正的成功。架構師工作的成功來自于項目的圓滿完成、用戶預期從項目成功中獲得的價值得到實現。〖=2〗1.6對架構師的學習和培養過程的幾點建議 除了以上闡述的成為架構師的路線圖，以及作為一名合格的架構師所應有的基本素質之外，作者對有志成為架構師的IT人士還有以下幾點建議。〖=1〗 在學習過程的*開始，明確說出作為程序員或者初級架構師在工作中所面臨的困惑，并記錄下來。在今后學習的過程中，不時拿出這些困惑來再讀一讀，看看是不是有的困惑已經得到了解決；同時記錄下新的困惑和問題。 在學習過程的*開始以及階段性的開始，明確說出學習和實踐試圖達到的目標。這些目標必須是十分具體的，能在事后客觀地進行衡量看是否達到了，并根據不斷提高的現有認識水平提出更高層次的目標。 針對個人的具體情況，按照本書的建議列出為了達到目標所要學習的相關內容，對上面建議的路線圖進行個性化的豐富和完善。 下棋要找高手。和其他的架構師進行交流，尤其是在特定的設計原則和方法及其實際應用上進行交流，對于一個架構師的成長和提高十分有必要。而這個過程會很有收獲，也可以是很快樂的。 要使用合適的工具。如果你也認為僅僅帶上裝有榔頭、鉗子和改錐的工具包是不可能建成摩天大廈的，那么你就肯定會同意，必定需要合適的、貫穿軟件生命周期各個階段的、成熟的軟件工具，才有可能完成大型復雜系統的架構設計和具體實施。〖=2〗學習、實踐、總結、提高，這才是成為一名合格的架構師的必經之路。 1.7本書的主要內容 本書由3部分組成。〖=1〗 第1部分介紹系統集成架構的基礎，并對系統集成與面向服務架構（SOA）實施細節的各個方面進行介紹，理論與實踐并重。 ?Euclid ExtraoAp第1章如何成為一名架構師： 首先與讀者一起建立我們討論的共同起點，指出成為一名合格架構師的方向和路線草圖，并初步勾勒出合格架構師**的素質。同時，指導讀者設立一種能夠進行系統集成開發的技術環境。 ?Euclid ExtraoAp第2章為什么要進行系統集成： 對系統集成的歷史、必要性、大原則及實施預后進行初步的討論。 ?Euclid ExtraoAp第3章系統之間相互作用的模式： 主要探討參與集成的各個系統之間相互作用的方式、適用范圍及其優缺點。 ?Euclid ExtraoAp第4章常見的參與集成的功能系統： 列舉常見的參與集成的系統本身的功能，比如數據庫、客戶管理系統（CRM）、企業資源計劃（ERP）系統、BPM、復雜事件處理（CEP）等，以便讀者對經常碰到的、需要進行集成的系統有一個大致的了解。 ?Euclid ExtraoAp第5章究竟何為服務： 這是一個老話題，但常常沒有說清楚。 ?Euclid ExtraoAp第6章系統集成項目的實施步驟： 介紹典型的系統集成項目的具體實施細節，包括整個生命周期的各個環節。 ?Euclid ExtraoAp第7章具體項目與公共服務： 介紹如何將每個具體項目都需要使用的普遍性的服務模塊單獨進行開發，并利用標準化的項目模板來對每個具體項目進行實施，從而避免公共服務功能部分的重復實施，讓每個項目專注于解決各自具體的業務問題。公共服務除了與業務有關的部分外，還包括安全、監視和管理以及運行維護方面的內容，但這部分內容不是本書的重點，僅僅是圍繞重點涉及到的話題，所以點到為止。 ?Euclid ExtraoAp第8章SOA的實施、局限性及解決方法： 回顧SOA應用十幾年來所產生的效果，分析其局限性，以及相應解決方法的展望。 第2部分在第1部分的基礎上引入現代API的概念，并就API對于企業業務發展的意義、圍繞API開發工作的具體細節、API與其他相關技術的關系等，結合實踐進行詳細的闡述。 ?Euclid ExtraoAp第9章現代API的引入及應用互聯網的概念： 介紹API的概念、使用API后企業對業務和IT可期待的愿景，以及API與系統集成的關系。 ?Euclid ExtraoAp第10章圍繞API的開發工作的內容： 詳細介紹API開發和應用中的技術細節、以API為主導的架構設計，以及對企業IT部門與業務部門之間的互動帶來的影響。 ?Euclid ExtraoAp第11章API與微服務： 從理論和實踐的角度論述API與十分流行的微服務之間的聯系與區別。 ?Euclid ExtraoAp第12章API與云計算： 對API的部署環境，特別是目前迅速興起的云計算環境，以及API的部署模式進行介紹。 ?Euclid ExtraoAp第13章*佳實踐的經驗： 對開發和應用API的過程中積累下來的經驗及教訓進行總結和概括。 ?Euclid ExtraoAp第14章API經濟： 當每一個企業以及企業里的每一個項目都按照API的架構思想進行實施，業務資源以API的形式系統地呈現時，就會形成一個應用網絡（Application Network）。而這個網絡也是企業價值鏈的網絡，即以API支撐的經濟體。這一章將對API經濟進行初步的介紹，并引入企業數字化轉型的話題。 第3部分是技術以外的隨感。 ?Euclid ExtraoAp第15章架構師的人文情懷： 這部分內容天馬行空，對技術方面的感悟、與人溝通的軟實力、架構師的教育和職業規劃，甚至學習過程的分析等都有涉及，十分隨意。 〖=2〗1.8總結 本章首先澄清了什么是架構，什么是架構師。然后對不同階段和不同角色的相關人員目前就大型復雜系統架構的理解所處的狀態進行了分類，作為學習過程中不同階段的代表。 隨后，本章列出了一份通往架構師之路的路線圖簡介，同時還拋出了作者眼里優秀架構師必須具備的素質，以及針對成為架構師的學習過程的幾點建議。本書各章的內容安排也是按照這個路線圖展開的。 和其他很多技能一樣，成功地成為一名優秀的架構師必須通過實踐，沒有“捷徑”可走。本章*后選用（而不是推薦）了可以免費獲得的一個系統集成及API的開發和部署平臺，供讀者練手，并得以對抽象的設計原則利用實例進行具體的說明。 在這個歷程的終點回報豐厚，而過程本身也可以是充滿樂趣的。你準備好了嗎？ ……
書友推薦
- >
名家帶你讀魯迅:故事新編
- >
伯納黛特,你要去哪(2021新版)
- >
小考拉的故事-套裝共3冊
- >
【精裝繪本】畫給孩子的中國神話
- >
推拿
- >
月亮虎
- >
我與地壇
- >
人文閱讀與收藏·良友文學叢書:一天的工作
本類暢銷
