架構(gòu)這個概念，和計算機科學（包括近幾年才成為一級學科的軟件工程）的其他術語類似，都是從傳統(tǒng)學科借用來的。這是因為計算機科學太年輕、發(fā)展太快，來不及形成自己特有的術語和名詞。因此，在學習和思考方法上，常常推薦類比法，嘗試用一些耳熟能詳?shù)氖挛锶ダ斫夂徒忉層嬎銠C科學領域的概念，以求“老嫗能懂”的效果。
這里介紹的一些內(nèi)容，大多是個人在學習和實踐過程中的一些思考和體會，以及平時的一些學習筆記整理而成，還很不成體系，還有很多需要繼續(xù)推敲的地方。我會在未來的工作實踐中更加深入思考，廣泛參考領域內(nèi)的成果，力求概念準確，容易理解。也歡迎各位同行專家不吝賜教。
關于架構(gòu)概念的學習和理解，我建議從2個方面入手：
第一、這個概念來自于建筑工程領域，要深入準確地理解，需要看一些建筑方面的資料，比如我會看梁思成《圖像中國建筑史》手繪圖，從中體會什么是架構(gòu)；我也會到建筑工地去看建筑施工的一些情況；還會在旅游時有意識地關注不同樣式的建筑，體會其架構(gòu)的不同?！敖ㄖ悄痰囊魳贰?，我們要試圖體會架構(gòu)之美。
第二、對于計算機科學與工程實踐中總結(jié)出來的一些架構(gòu)，我們要通過實踐來學習和領會。比如對于MVC架構(gòu)，我們是否聯(lián)想到用VC++編程時 “ Document/View ” 模型？比如說到三層架構(gòu)或者多層架構(gòu)，我們是否考慮到與 “ Client/Server ” 二層架構(gòu)的關系。
架構(gòu)工作，不管有沒有架構(gòu)師被指派，其實都是會做的，只是有些時候，架構(gòu)工作被做了，但沒有人意識到。
有明確的架構(gòu)師，可能會使架構(gòu)工作更加專業(yè)化，可能對提高架構(gòu)的質(zhì)量有幫助；但并不是只有架構(gòu)師才可以做架構(gòu)工作。
我們應該把架構(gòu)師當成一種角色，而不僅僅是一個頭銜、一個位子。也許有很多人的工作頭銜是架構(gòu)師，但其實際工作和架構(gòu)關系不大，也可能有些人沒有架構(gòu)師頭銜，但其在實際工作中衛(wèi)架構(gòu)正在做貢獻。
As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:
圖中，TOGAF把企業(yè)架構(gòu)分為4個部分：
1.Business architecture—Describes the processes the business uses to meet its goals
第一、業(yè)務架構(gòu)。描述業(yè)務流程及其達成的業(yè)務目標。
2.Application architecture—Describes how specific applications are designed and how they interact with each other
第二、應用架構(gòu)。描述具體的應用系統(tǒng)的設計以及相互之間的關系。
3.Data architecture—Describes how the enterprise datastores are organized and accessed
第三、數(shù)據(jù)架構(gòu)。描述企業(yè)的數(shù)據(jù)存儲以及訪問方式。
4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions
第四、技術架構(gòu)。描述基礎設施如何支持應用系統(tǒng)的運行及交互。
其中，一個重要的理念是業(yè)務架構(gòu)與應用架構(gòu)的映射關系（依賴、推理）。應用架構(gòu)要基于業(yè)務架構(gòu)來考慮，而不是憑空想象。應用是業(yè)務能力的提供者。
很多時候，IT部門、以及IT部門的一些人，常常把自己當成數(shù)據(jù)的所有者，導致認為地制造了藩籬，阻礙數(shù)據(jù)的共享及訪問。其實，IT通常應該只是“司機”的角色。角色錯位了，想做事正確？難于緣木求魚。
這里強調(diào)數(shù)據(jù)，是因為數(shù)據(jù)是對客觀世界的反映，而我們的每一個應用，不過是客觀世界的一個視圖。
數(shù)據(jù)是最基本的。數(shù)據(jù)可以被處理、解釋而得到各種信息，而信息又可以被挖掘出有用的知識。我們也可以從中理解當今所謂DT的重要性，以及大數(shù)據(jù)時代，數(shù)據(jù)就像工業(yè)時代的石油一樣重要。
架構(gòu)是客觀存在的，不管我們是否有意識地考慮它。架構(gòu)不是孤立存在的，它是在具體的上下文環(huán)境中，為達到明確的目標而存在的。架構(gòu)不是“屠龍術”。
“規(guī)劃-架構(gòu)-設計”這三者是緊密聯(lián)系的，常常被混為一體的。為了理解這些概念的聯(lián)系和區(qū)別，我們可以與市政規(guī)劃進行類比。巴西利亞的建城史、華盛頓的城市規(guī)劃，其理念值得我們在考慮架構(gòu)時借鑒。
這里把規(guī)劃提取出來，而不是與架構(gòu)混為一談，是為了有助于理解思考與實踐的不同階段和步驟，幫助思維更加清晰。從軟件工程與建筑工程的類比，更容易地理解架構(gòu)和規(guī)劃。另外，“自頂向下，逐步細化”的結(jié)構(gòu)化思想也清晰可見。我們推崇面向?qū)ο蟮姆椒ǎ驗樗c客觀世界的實際情況更接近，同時，我們也要繼承和發(fā)揚結(jié)構(gòu)化方法。
所有的架構(gòu)都是設計，但不是所有的設計都是架構(gòu)。架構(gòu)可以認為是宏觀設計、頂層設計。
計算模式經(jīng)歷了幾個發(fā)展階段，我們選擇什么的模式，一方面要跟上技術發(fā)展的趨勢，另一方面要知道目的是什么。
第一、主機-終端（mainframe）
第二、個人計算機（PC）
第三、客戶機/服務器（C/S）
第四、分布式計算（網(wǎng)格、云計算等）
如果規(guī)模不大，采用分布式部署意義不大。
對解耦與服務化的關系進行深入思考，嘗試理解其本質(zhì)，明確什么事目的，什么是手段。在做決策的時候，就有助于分清主次。
對于企業(yè)應用架構(gòu)向“微”服務演化，解耦是基礎。為此，在程序?qū)崿F(xiàn)時，“單一職責”原則需要尊循。即使不走服務化道路，降低耦合度也是好的。
是否可以假定：一般情況下，對于特定的語言環(huán)境，比如：java和C#，較少的代碼行很難實現(xiàn)多個業(yè)務功能？于是以子程序(函數(shù)，過程，方法)代碼行數(shù)對工程師執(zhí)行“單一職責”原則進行度量。
對于不同語言，建議對開發(fā)小組的代碼行進行統(tǒng)計，經(jīng)過一段時間的積累得出合適的經(jīng)驗值。一般地，這個代碼行數(shù)的經(jīng)驗值是和小組的能力相關的。
敏捷方法的使用離不開迭代，我們需要合理地使用這兩種方法，才能使我們的交付物越來越逼近用戶的真實需求。
這里提到了用戶的真實需求，我也多說幾句。用戶的需求不應該是我們作為BSA或者SME假設出來的，而是我們通過各種有效的方法，比如訪談，從用戶那里捕獲的。即使我們對用戶的建議是正確的，幫助用戶完善需求的，也一定要取得用戶的完全理解并由用戶正式確認。
沒有分工，協(xié)作就是一句空話。沒有明確的分工，就會造成扯皮等現(xiàn)象。分工有助于提高效率和質(zhì)量。要想分工，就要做好功能分解。而功能分解到合適的粒度，也可以認為是服務化的基礎。
微服務所倡導的“單一職責”，其實質(zhì)也是明確責任，消除歧義。簡單即美，大道至簡。單一職責恰恰符合這個原則。
從這個對制造別針的分工的描述，你會體會到并發(fā)現(xiàn)，很多基本道理是相通的，不論對于生產(chǎn)制造還是軟件開發(fā)。這就是道法自然。
演化這個詞越來越流行了，但仔細想一想，有些情況演化的周期是很長的。就像不可降解的塑料制品，其以無害身份重新回歸自然需要幾百年甚至更長的時間。考慮演化時，也要結(jié)合軟件/應用系統(tǒng)的生命周期，否則失去意義。
單靠演化，即使能使架構(gòu)越來越優(yōu)化，也可能需要很長的周期，而對于產(chǎn)品或者項目，時間這個約束條件往往是苛刻的。
如前面所闡述，迭代是有條件的。我的建議是：在有規(guī)劃的基礎上進行演化。我們無法得到普適的架構(gòu)，但可以得到確定領域的通用架構(gòu)，可以在特定領域通過演化使應用架構(gòu)逐步優(yōu)化，逐步與業(yè)務架構(gòu)想適應，提高匹配度。
簡化架構(gòu)，應該成為架構(gòu)師的常識和日常必須考慮的事情。復雜的架構(gòu)，特別是強依賴對業(yè)務的影響很大：
分布式的計算模型是以RPC為基礎展開的，為解決應用系統(tǒng)間的集成和互操作，為支持語言和平臺獨立性，經(jīng)歷了幾十年的發(fā)展歷程，從RPC到COM/COM+，以及CORBA和JavaBeans/EJB，進而發(fā)展到Web services，實現(xiàn)了跨平臺及語言無關。
如果不支持互操作，那么基于異構(gòu)組件搭建分布式計算平臺就是不可能的。
無論服務化還是分布式，都需要進程間通訊（IPC），也包括線程間的通訊。這樣，一個好的通訊協(xié)議是必要的。HTTP協(xié)議的設計初衷據(jù)說是為了人-機通訊，后來被用作機器間通訊（M2M），這是服務化/分布式的網(wǎng)絡基礎。
其他協(xié)議，也可以擔此大任。只是從復雜性、使用難易程度、普遍性等方面要多加考慮。比如傳統(tǒng)的web services，其SOAP協(xié)議除了可以基于HTTP，還可以基于 SMTP。
通過調(diào)研，我們發(fā)現(xiàn)企業(yè)應用系統(tǒng)面臨的三個主要痛點：
第一、靈活性差
第二、交付時間長，動輒3個月或者半年乃至一年
第三、性能差，用戶體驗不好
針對靈活性差，我們提出要降低耦合度，這也是軟件工程中的一個基本原則。這樣的問題，反映出我們的軟件設計、開發(fā)水平不高的現(xiàn)實，專業(yè)性查，很多時候，很多開發(fā)人員還分不清程序和軟件的區(qū)別，還只停留在功能實現(xiàn)的低水平上。這不單是靠架構(gòu)優(yōu)化能解決的，而是要靠提高整體開發(fā)水平來解決。
針對交付時間長，我們考慮從提高重用和構(gòu)件化等方面著手，不斷積累企業(yè)應用構(gòu)件庫。這好比我們燒磚建房，我們從實際需求出發(fā)，逐步建立并不斷更新有限的磚塊規(guī)格集合，未來所有的房屋都使用標準件來搭建。
針對性能問題，我們在構(gòu)件化的基礎上逐步地適度地服務化，這樣講是因為我們認為，不是所有的應用系統(tǒng)都適合服務化。有了這樣的基礎，我們對系統(tǒng)的擴展，包括水平和垂直，都會變得容易，分布式的部署水到渠成。
通過前面的痛點及解決方案的分析，我們總結(jié)了好的企業(yè)應用架構(gòu)的三要素，同時也作為我們的三步走戰(zhàn)略：
第一、組件化/構(gòu)件化
第二、服務化
第三、分布式環(huán)境
“對象-組件-服務”示意圖希望表達三者之間的關系，有助于理解組件化是服務化的基礎。對于非面向?qū)ο笳Z言程序設計，也可以支持服務化，此處不做深入探討。
服務化是和多進程/多線程相關的，是降低應用部署粒度的過程。而分布式部署，其基礎是進程/線程間的通信。要理解RPC，最好首先理解IPC，這個前面已有論述。
這是我們針對企業(yè)應用系統(tǒng)服務化而開發(fā)的模型，考慮了多種邏輯和物理架構(gòu)。結(jié)合企業(yè)應用，基于多層分布式體系結(jié)構(gòu)而進行的實例化。我們希望該模型能夠覆蓋企業(yè)的全部應用，包括基于package的二次開發(fā)系統(tǒng)（如SAP，Oracle），基于SaaS的云應用（如SFDC），以及基于Java/.Net自開發(fā)的一些應用。我們正在實踐中逐步完善這個模型，希望能為企業(yè)架構(gòu)的優(yōu)化助力。
這里希望對這幾個相關的概念做簡單的對比，以便大家在學習、看文章時、討論時，能夠在合適的語境。
Web Service，由于需要WSDL以及skeleton，導致比較“重”，但支持復雜的數(shù)據(jù)結(jié)構(gòu)。
Micro Service，主要是指粒度??；再有就是不需要WSDL以及skeleton，因此輕量。
對于微服務（Micro-services）和大數(shù)據(jù)(Big Data)這2個術語的理解，不能望文生義。微是為了表示粒度的足夠小，但小到什么程度合適，一方面見仁見智，另一方面應該結(jié)合實際項目實際問題。拿瓷磚和馬賽克為例，我們不會在需要使用瓷磚的地方都使用馬賽克來拼湊。
'webservice' and 'microservice' aren't mutually exclusive terms, nor do they have strict, objective definitions. It's possible that all of your web services already are microservices by many people's definitions.
Web services architecture: the service provider sends a WSDL file to UDDI. The service requester contacts UDDI to find out who is the provider for the data it needs, and then it contacts the service provider using the SOAP protocol. The service provider validates the service request and sends structured data in an XML file, using the SOAP protocol. This XML file would be validated again by the service requester using an XSD file.
How big is a microservice?
Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.
This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.
這里想強調(diào)的是SOA與Web Services不是一個概念，很多時候，這2個概念卻常常被不恰當?shù)鼗煊谩?br>
The vision behind SOA and Web Services comes from enterprise and organization needs to save development effort and money by reusing software in the form of components.
在SOA和WebServices背后的想法是，企業(yè)和組織希望通過復用組件以達到節(jié)省成本的目的。
The Web Services vision achieves reuse by building service components that autonomously discover at runtime other needed components needed to solve a business process.
Web Services的愿景是，通過構(gòu)建服務組件，支持自動發(fā)現(xiàn)解決業(yè)務流程問題，實現(xiàn)對復用的支持。
The SOA vision achieves reuse by aligning new software development projects to business goals through a governance plan.
SOA的愿景是，通過治理使新的軟件項目和業(yè)務目標一致
Both expect a registry of services will help avoid building the same software component twice.
二者都希望通過注冊機制避免童顏個的組件開發(fā)兩次（重復開發(fā)）。
在 Sam Newman 的《Building Microservices》一書中，SOA 和 Micorservices 的區(qū)別給出了定義：
You should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.
你可以把微服務想成是 SOA 的一種實踐方式，正如 XP 或 Scrum 是敏捷軟件開發(fā)的實踐方式。
面向服務架構(gòu)（SOA）的概念已有十多年，它提出了一種架構(gòu)設計思想， 但沒有給出標準的參考實現(xiàn)，當微服務架構(gòu)出現(xiàn)時， 其擁護者開始拒絕使用包裹著失敗陰影的 SOA 這個標簽，而直接稱其為微服務架構(gòu)（Microservices Architecture Style）， 讓人以為是一套全新的架構(gòu)思想，但事實上它的本質(zhì)依然是 SOA 的一種實踐方式。
The core difference between SOA and microservices lies in the size and scope. As the word 'micro' suggests, it has to be significantly smaller than what SOA tends to be.
Microservice is a small(er) independently deployable unit. Beware of very small microservice antipattern - nanoservice.
A SOA can be either a monolith or it can be comprised of multiple microservices.
SOAP, or Simple Object Access Protocol, is an architectural concept that was created in 1998 by Dave Winer, Don Box, and Bob Atkinson, in collaboration with Microsoft. Designed explicitly for the purpose of making communication between web services easier.
SOAP，簡單對象訪問協(xié)議，是在1998年由Dave Winer, Don Box, and Bob Atkinson, in collaboration 在微軟公司合作時創(chuàng)造的架構(gòu)概念，設計的初衷是為了web service之間通訊更容易。
REST, or Representational State Transfer, was created in 2000 by Roy Fielding in UC, Irvine; later versions of this architecture were created in collaboration with the W3C Technical Architecture Group (TAG).
REST，表述性狀態(tài)轉(zhuǎn)移，由Roy Fielding在2000年在UC, Irvine創(chuàng)造，后續(xù)的版本是與W3C的TAG合作推出的。
While SOAP aimed to be a complete system, REST was designed to be more lightweight for building the following right into the design.
SOAP的目標識一個完整的系統(tǒng)，而REST傾向于更加輕量。
Extensibility through user generated extensions tying into the base structure;
Neutrality by operating over any transport protocol;
Independence by allowing variable programming paradigms and structures;
Large Data Handling by handling conversions, calculations, etc. asynchronously;
Scalability by using cached data from the client and intermediate nodes built into HTTP to self-define;
Portability by tying the transfer of data to the program code during transfer;
Extensibility by allowing individual elements of the greater network to develop independent of one another, using uniform interfaces.
https:///2yko4TbC8cI?t=15m53s
Edit : Here is another video by Martin Fowler, talking about difference between Microservices and SOA.
https:///wgdBVIX9ifA?t=13m10s
微信號：freshmanTechnology
