全文網址
http://msdn.microsoft.com/en-us/magazine/ff714590.aspx
After the explosion of Web applications to accommodate high-traffic usage,
the next big wave has become service-oriented architecture (SOA).
SOA is destined to become a standard way
for developing extremely scalable applications,
and cloud computing platforms like Windows Azure represent a giant leap
in moving SOA toward achieving this goal.
SOA allows users to distribute applications to multiple locations,
multiple departments within an organization,
and multiple businesses across the Internet.
Plus, it permits reuse of existing code within an organization and,
more importantly, collaboration among different business units.
A SOA application is usually deployed in a server farm
in a load-balanced environment. The goal is to allow the application
to handle as much load as you throw at it. The question thus becomes:
What are some of the considerations you should have in mind
for improving both performance and scalability of your SOA application?
Although SOA, by design, is intended to provide scalability,
there are many issues you must address
before you can truly achieve scalability.
Some of these issues involve how you code your SOA application,
but the most important bottlenecks often relate to
how you store and access your data.
I’ll explore those issues and provide some solutions in this article.
(全文請由網頁觀看)
======================================================================
這篇文章對我個人來說，它具有提醒的意義。
但並非與文章提到的如何指出架構延展性上的瓶項。
對於發展一個服務平台來說，
許多由小型走向中型的服務都有機會遇到架構延展性的問題。
『延展性』，需要達到什麼樣的效果呢？
服務的架構是否能透過增加機器，並簡單地設定就能處理更多的服務需求？
對一般終端使用群來說，最常見的就是 Web 服務。
當我們服務對向少時，我們的架構能夠很簡單。
直接在 Server Side 程式讓它直接取用資料庫。
以 Java 來說就是用 JDBC API 建立連線，
依請求內容下達 SQL 指令，最後組合一下 View 回應至瀏覽器。
這樣的設計方式相當容易理解，實作、學習上也沒什麼難題。
許多關於 Web 應用程式設計的入門書也是這麼教的。
頂多是不同的語言、不同的 Web Framework 自有一套文化。
但以架構的觀點來說，這與新手入門等級的『留言版』程式是相同的。
這種『留言版』式的架構要如何最佳化呢？
首先是 IO 效能的改善，那麼重點就會在：
改善 DB Server 並導入 Cache System。
但幫助的有限，因為真實與資料庫存取與實際邏輯運算都還在 Web App 上。
如果我們增加機器，那就是多加一組 Cache System 跟 DB Server 的『負擔』
而全部都綁在一起的結果，就是試途改變任合一部分，其於不相關的部分都被迫改變。
像導入 Cache System 時，若在 API 支援上沒有一個抽象層，
那就會在 Web App 上多許了 if/else：
if cached:
return cached_data
else:
return do_real_logic()
相樣的情況，也有機會在 DB Access 最佳化時上演。
回歸到架構來說，要開始面對擴充性、延展性的議題，
讓資料存取的方式利用間接層抽象化才能佔據最佳的攻擊位置。
而這一步問一的心理障礙就是，
「為什麼我不能直接用 JDBC API，它又快又方便，
要再透過別的 API 去間接使用它，實在很愚蠢」
這類的質疑是第一線開發者，或最初設計者常見的心聲。
無論是被質問，或是在心中反問自己！
架構上的調整，為了面對擴充性、延展性會引入更多的技術，
並且在局部上變更架構的設計。
例如資料的分區，我們可能會依不然的用者，將資料放到不同的 DB Server。
難道開發者想要：
if user_in_region_A:
use_region_A_jdbc ...
if user_in_region_B:
use_region_B_jdbc ...
if user_in_region_C:
use_region_C_jdbc ...
這是簡單地資料分流設計，但它的細節需被封裝起來。
不然只會帶來更多的麻煩，並讓開發者昇級會麻煩製造者。
過程中會導入的技術可能不只是 Relational Database 的，
也有 NoSQL 的相關技術，這些內容加上無所不在的快取機制，
不在架構上加入抽象化的間接層會讓開發者難以維護。
而 SOA 並非必要選項，但它的義涵大過於實質的規格。(針對非 B2B 來說)
看到這篇文章才讓我警覺，為何現在面對的舊有的架構對於改變是較抗拒的。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.231.51.117