资深架构专家聊架构之道：规划、简化和演化（续）
李曉時，超過 20 年 IT 行業經驗；資深架構專家，《架構寶典》聯合作者。
上文 《資深架構專家講解微服務治理的架構演進》分享了架構規劃
11
? ?
規劃還是演化？對架構影響的思考
演化這個詞越來越流行了，但仔細想一想，有些情況演化的周期是很長的。就像不可降解的塑料制品，其以無害身份重新回歸自然需要幾百年甚至更長的時間。考慮演化時，也要結合軟件/應用系統的生命周期，否則失去意義。
12
? ?
缺少規劃，難以演化
單靠演化，即使能使架構越來越優化，也可能需要很長的周期，而對于產品或者項目，時間這個約束條件往往是苛刻的。
如前面所闡述，迭代是有條件的。我的建議是：在有規劃的基礎上進行演化。我們無法得到普適的架構，但可以得到確定領域的通用架構，可以在特定領域通過演化使應用架構逐步優化，逐步與業務架構想適應，提高匹配度。
13
? ?
簡化架構是必要的
簡化架構，應該成為架構師的常識和日常必須考慮的事情。復雜的架構，特別是強依賴對業務的影響很大：
維護成本增加
集成測試/回歸測試成本增加，即使對于微小的改變
引入 BUG 的可能性增大
對于縮減投資的系統存在單點故障的可能性增大
難于在復雜的系統架構和業務間轉換
管理和審計難度大成本高
難于用新技術替換不被支持的過時的技術
13.1
? ?
常用分布式組件互操作及接口定義
分布式的計算模型是以 RPC 為基礎展開的，為解決應用系統間的集成和互操作，為支持語言和平臺獨立性，經歷了幾十年的發展歷程，從 RPC 到 COM/COM+，以及 CORBA 和 JavaBeans/EJB，進而發展到 Web services，實現了跨平臺及語言無關。
如果不支持互操作，那么基于異構組件搭建分布式計算平臺就是不可能的。
14
? ?
服務化/分布式的網絡基礎
無論服務化還是分布式，都需要進程間通訊（IPC），也包括線程間的通訊。這樣，一個好的通訊協議是必要的。HTTP 協議的設計初衷據說是為了人-機通訊，后來被用作機器間通訊（M2M），這是服務化/分布式的網絡基礎。
其他協議，也可以擔此大任。只是從復雜性、使用難易程度、普遍性等方面要多加考慮。比如傳統的 web services，其 SOAP 協議除了可以基于 HTTP，還可以基于 SMTP。
15
? ?
從架構角度解決企業應用痛點
通過調研，我們發現企業應用系統面臨的三個主要痛點：
靈活性差
交付時間長，動輒 3 個月或者半年乃至一年
性能差，用戶體驗不好
針對靈活性差，我們提出要降低耦合度，這也是軟件工程中的一個基本原則。這樣的問題，反映出我們的軟件設計、開發水平不高的現實，專業性差，很多時候，很多開發人員還分不清程序和軟件的區別，還只停留在功能實現的低水平上。這不單是靠架構優化能解決的，而是要靠提高整體開發水平來解決。
針對交付時間長，我們考慮從提高重用和構件化等方面著手，不斷積累企業應用構件庫。這好比我們燒磚建房，我們從實際需求出發，逐步建立并不斷更新有限的磚塊規格集合，未來所有的房屋都使用標準件來搭建。
針對性能問題，我們在構件化的基礎上逐步地適度地服務化，這樣講是因為我們認為，不是所有的應用系統都適合服務化。有了這樣的基礎，我們對系統的擴展，包括水平和垂直，都會變得容易，分布式的部署水到渠成。
16
? ?
企業應用架構服務化遷移步驟
通過前面的痛點及解決方案的分析，我們總結了好的企業應用架構的三要素，同時也作為我們的三步走戰略：
組件化/構件化
服務化
分布式環境
“對象-組件-服務”示意圖希望表達三者之間的關系，有助于理解組件化是服務化的基礎。對于非面向對象語言程序設計，也可以支持服務化，此處不做深入探討。
服務化是和多進程/多線程相關的，是降低應用部署粒度的過程。而分布式部署，其基礎是進程/線程間的通信。要理解 RPC，最好首先理解 IPC，這個前面已有論述。
17
? ?
企業應用系統服務化參考模型
這是我們針對企業應用系統服務化而開發的模型，考慮了多種邏輯和物理架構。結合企業應用，基于多層分布式體系結構而進行的實例化。我們希望該模型能夠覆蓋企業的全部應用，包括基于 package 的二次開發系統（如 SAP，Oracle），基于 SaaS 的云應用（如 SFDC），以及基于 Java/.Net 自開發的一些應用。我們正在實踐中逐步完善這個模型，希望能為企業架構的優化助力。
18
? ?
淺談幾個相關的概念
這里希望對這幾個相關的概念做簡單的對比，以便大家在學習、看文章時、討論時，能夠在合適的語境。
9
? ?
Web Service 與 Micro Service
Web Service，由于需要 WSDL 以及 skeleton，導致比較“重”，但支持復雜的數據結構。
Micro Service，主要是指粒度小；再有就是不需要 WSDL 以及 skeleton，因此輕量。
對于微服務（Micro-services）和大數據(Big Data)這 2 個術語的理解，不能望文生義。微是為了表示粒度的足夠小，但小到什么程度合適，一方面見仁見智，另一方面應該結合實際項目實際問題。拿瓷磚和馬賽克為例，我們不會在需要使用瓷磚的地方都使用馬賽克來拼湊。
"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.
10
? ?
Web Service 與 SOA
這里想強調的是 SOA 與 Web Services 不是一個概念，很多時候，這 2 個概念卻常常被不恰當地混用。
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 背后的想法是，企業和組織希望通過復用組件以達到節省成本的目的。
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 的愿景是，通過構建服務組件，支持自動發現解決業務流程問題，實現對復用的支持。
The SOA vision achieves reuse by aligning new software development projects to business goals through a governance plan. SOA 的愿景是，通過治理使新的軟件項目和業務目標一致
Both expect a registry of services will help avoid building the same software component twice.
二者都希望通過注冊機制避免同一個的組件開發兩次（重復開發）。
11
? ?
Micro Service 與 SOA
在 Sam Newman 的《Building Microservices》一書中，SOA 和 Micorservices 的區別給出了定義：
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 是敏捷軟件開發的實踐方式。
面向服務架構（SOA）的概念已有十多年，它提出了一種架構設計思想， 但沒有給出標準的參考實現，當微服務架構出現時， 其擁護者開始拒絕使用包裹著失敗陰影的 SOA 這個標簽，而直接稱其為微服務架構（Microservices Architecture Style）， 讓人以為是一套全新的架構思想，但事實上它的本質依然是 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.
12
? ?
SOAP 與 REST
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，簡單對象訪問協議，是在 1998 年由 Dave Winer, Don Box, and Bob Atkinson, in collaboration 在微軟公司合作時創造的架構概念，設計的初衷是為了 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，表述性狀態轉移，由 Roy Fielding 在 2000 年在 UC, Irvine 創造，后續的版本是與 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 的目標是一個完整的系統，而 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.
13
? ?
參考資料
Martin Fowler:
https://youtu.be/2yko4TbC8cI?t=15m53s
Edit : Here is another video by Martin Fowler, talking about difference between Microservices and SOA.
https://youtu.be/wgdBVIX9ifA?t=13m10s
推薦閱讀
微服務架構最強講解，通俗易懂，寫得太好了！
2021-06-21
標簽類目體系的價值與意義
2021-06-18
程超：突破瓶頸！如何不斷的提高自己
2021-06-17
資深架構師手把手教你性能優化
2021-06-07
李偉山：金融撮合架構
2021-05-31
阿里專家晨末：什么是技術一號位？
2021-07-08
資深架構專家聊架構之道：規劃、簡化和演化
2021-07-01
總結
以上是生活随笔為你收集整理的资深架构专家聊架构之道：规划、简化和演化（续）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微信支付软件架构重构之旅
- 下一篇： hdu-Find the nondecr