Software Architecture Patterns 2

O'Reilly 提供了一份Software Architecture Patterns [Book] ，裡面描述了五個基本的軟體架構。這邊是 microkernel, microservices。

Microkernel

也稱為 plug-in architecture pattern，常用於 product-based applications。product-based application 就是分別封裝且可分版本下載的 third-party product，有獨立的versions, release notes, pluggable features。本 pattern 可利用 plug-ins 增加 application features。

本架構有兩個元件：a core system & plug-in modules，applicaiton logic 會切割分配在 plug-in modules 與 core system，各自獨立，提供 extensibility, flexibility, isolation of app features, custom processing logic

core system 包含系統運作的最小功能，大部分的 operationg system 都實作了 micro-kernel architecture pattern。

plugin-in modules 是獨立的元件，包含特殊附加的功能，擴充 core system，通常 plugin 是獨立的，但也可以引用其他 plug-in。

plugin module 可用多種方式連接到 core system，包含 OSGi (open ervice gateway initiative), messaging, web serives, point-to-point binding (ex: object instantiation)，由 application 規模決定用哪一種方法。pattern 並沒有限制用哪一種方法，唯一的要求是 plug-in 之間要互相獨立。

plug-in 與 core system 之間的 contract 可以是標準或自訂的，custom contact 發生在 plug-in component 是由無法控制的 3rd party 開發，在這種狀況，可以開發 adapter，做 standard contact 與 custom contract 的轉換，記得一開始開發就要有 versioning strategy

example: Eclipse IDE

example: Internet Browser

注意事項

如果有某些常常改變的地方，就不能在整個系統都用這個 pattern，可以搭配 layered/event-driven/microservices architecture 使用。

microservice architecture pattern 特別適合支援 incremental development。

對於 product-based application，microkernel architecture 是第一選擇，因為可以隨著時間慢慢提供新的功能。

Pattern 分析

• overall agility: high

• ease of deployment: high

• testability: high

  plug-in modules 可以單獨獨立測試

• performance: high

• scalability: low

  product-based application 通常是單機運作

• ease of development: low

  需要另外開發，並管理 contract (versioning) ，開發比較麻煩

Microservices

service-oriented architecture

在選用架構時，有幾個基本概念

1. separately deployed unit

   每個 microservice 都會被單獨部署，可分別擴充 scalability，跟 application 分離

2. service component

   有可能是 single module 或是 application，service components 包含 1 到多個 modules，可能是單一功能，或大型 application 的一部分，設計正倔的 service component granularity 是 microservice 的一大挑戰

3. distributed

   所有元件都是 fully decoupled，以某種 remote access protocol 使用 (ex: JMS< AMQP, REST, SOAP, RMI ...)

microservice architecture 是由兩種架構延伸合併起來的：

1. monolithic application developed using the layered architecture pattern

2. distributed applications developed through service-oriented architecture (SOA) pattern

Pattern Topologies

雖然有很多實作方法，但主要有三種常見熱門的 topologies

1. API REST-based

   

   very fine-grained service components

   透過 REST-based interface 存取，通常是單獨部署的 web-based API layer

   ex: cloud-based RESTful web services by Yahoo, Google, Amazon

2. application REST-based

   

   client 發送 request 給傳統 web-based or fat-client business application，而不是 simple API layer

   user-interface layer 是獨立部署的 web application，會遠端存取 simple REST-based interface

   這種 service component 會比 API REST-based 大, more coarse-grained

   本架構通常是 small to medium sized business application 使用，減少架構複雜度

3. centralized messaging

   

   類似上一個 application REST-based topology，中間用 lightweight centralized message broker (ActiveMQ, HornetQ) 取代 REST for remote access。不要將這個 pattern 跟 SOA 混淆。lightweight message broker 並不執行任何服務協調工作，單純只做 transformation, complex routing，換句話說，就是一個 lightweight transport to access remote service components

   centralized messaging topology 在大型 application 或是有兩個 application互相溝通時有被使用。這個架構的優點是 advanced queuing mechanisms, asynchronous messaging, monitoring, error handling, better overall load balancing, scalability。

   但 centralized messaging broker 可能有單點失效問題

避免相依性

本架構的挑戰：決定 correct level of granularity for service components

如果太 coarse-grained，可能會無法得到這些優點: deployment, scalability, testability, loose coupling

如果太 fine-grained，可能會變成 heavyweight service-oriented architecture，complexity, confusion, expense 的 SOA-based applications

如果 service component 之間需要協調溝通(順序)，或是 service 之間需要 inner-service communcation，就可能是元件太 fine-grained

inner-service communcation 可以用 shared databased 取代，但要重複實作 shared function (違反 DRY don't repeat yourself)，這是 tradeoff，可易用 unitity class 處理這個部分

注意事項

主程式被切割為更小，更容易部署的單位，以 microservice 開發的應用，more robust, better scalabilty，更容易做持續開發

可作 rela-time production deployments，而不是一個月或一週一次大型部署

可以實作偵測 hot-deployment，並指向 error/waiting page，可 real-time 切換多個 service component instances

跟 event-driven architecture 有一樣的問題: contract creation, manitenance, goverment, remote system availability, remote access authentication and authorization

Pattern 分析

• overall agility: high

• ease of deployment: high

• testability: high

• performance: low

• scalability: high

• ease of development: high

References

软件架构入门 - 阮一峰的网络日志

Software Architecture Patterns 1

O'Reilly 提供了一份Software Architecture Patterns [Book] ，裡面描述了五個基本的軟體架構。這邊是 layered 與 event-driven architecture。

Layered

layered architecture 是最常見的架構，也稱為 n-tier architecture pattern。最初是因為 Java EE application 而變成顯學。

本架構分為四個基本的 layers：presentation, business, persistence, database，有時候可以簡化，將 business 與 persistence 合併為一個 business layer，也就是把 SQL, HSQL 放在 business layer component 裡面，適合小型專案。

layered architecture 最重要的功能，就是 separation of concerns among components。

本架構重要概念是: closed，也就是 request 必須一層一層轉換移動，不能跳躍。雖然有時候會遇到一些非常簡單的功能，可以直接將 presenation layer 的資料儲存到 database，但遵循本架構的原則：layers of isolation，不能破壞 layers 之間的階層關係。一但破壞這個開發原則，會讓 application 不容易修改，難以維護。

如果要解決 layers 的 overhead 與耗時，可以將 layer 由 closed 變成 open。例如加上一個 open 的 shared-service layer，這個 service layer 可區分 access restriction 的 service 及 common service。

Pattern 分析

• agility: low

  layers 提供了修改的彈性，但會多了一些 code 開發與執行時間的 overhead

• ease of deployment: low

  通常會更新整個 application，無法針對 compoent 單獨更新

• performance: low

• scalability: low

  這個架構適用於一個獨立的 application

• ease of development: high

  分層後，讓 code 容易維護

Event-Driven

這是常見的 distributed asynchronous architecture pattern，用來開發 scalable applications。

本架構包含兩個基本的 topologies: mediator 及 broker。mediator 用在一個 event 透過一個 central mediator 處理多個 steps。broker 用在 chain events together。因兩種架構的差異，在一開始要確定哪一種適用。

Mediator

當 event 有多個 steps，且有多個處理 event 的組合，可使用 mediator。

mediator 有四種 components: event queues, an event mediator, event channels, event processors

當 mediator 收到 event，會發送給不同的 event channel 處理某個 step，event processor 會監聽 channel，取得 event 並執行 business logic

在 event-driven architecture 可能會有上百的 event queues，並沒有限定如何如做 event queue，可能是 message queue/web serivce endpoint

event 有兩種 types: initial event 及 processing event

mediator 負責協調處理 initial event 的 steps，本身不執行 business logic，會發送 processing event 到 event channel 給 processor 處理

event channel 可以是 message queue 或是 message topics，在 mediator topology 比較常使用 message topics，因為可以派送給多個 event processors

event processor 包含了處理該 event 的 business logic，每個 processor 都是 self-contained, indepenedent, highly decoupled

event mediator 有多種實作方式，要選擇適用的方案

1. 使用 open source integration hubs，ex: Spring Integration, Apache Camel, or Mule ESB，通常是用 Java code 或 DSL(domain-specific language) 實作

2. 比較複雜的方法，使用 BPEL (business process execution language) ，open source BPEL engine 有 Apache ODE。BPEL 是 standard XML-like language

3. 最大型的 application，有複雜到中間有需要人工處理的步驟時，可以用 BPM (business process manager) ex: jBPM 實作

example

提出搬家資訊更新需求給保險公司，initial event: relocation event，要完成此 event 其中包含上圖多個步驟，mediator 會產生多個 processing event，並發送給 event channel，由 processor 處理，processing event 上面的箭頭線段代表那些 event 可以同時被處理

Broker

broker topology 沒有 central event mediator，message 以 chain-like 方式流過 lightweight message broker (ex: ActiveMQ, HornetQ)，當有簡單的 event processing flow 時可使用。

有兩個 components: broker, event processor

broker 可以是 centralized 或 federated，包含所有 event channels。event channels 可以是 message queue, message topics, 或兩者的組合。

event processor 負責處理 event 後，並產生下一個動作的新 event。

ex: an event processor 處理 portfolio of stocks 收到 initial event: stock split，收到該 event 會執行 portfolio rebalancing，然後發布一個新的 "rebalance portfolio" event 給 broker，接下來由另一個 processor 處理。

系統有可能會因為某些特殊狀況 ex: 升級，發生某些 event 沒有被 processor 處理的狀況

example: 提出搬家資訊更新需求給保險公司

"customer process" 接收 initial event，修改客戶的地址，並發送 "change address event"。"quote process" 與 "claims process" 對這個 event 有註冊要使用該 event。

"quote processor" 會根據地址重新計算新的 auto-insurance rate，並發布 "recalc quote event" 給系統。 "claims process" 接收到 "change address event" 會更新 outstanding insurance claim，並發布 "update claim event" 給系統。

event processor 會處理新的 event，直到沒有新的 events

broker topology 是用 chaining of events 執行 business function，就像是接力賽跑一樣。

注意事項

因為 asynchronous distributed 特性，event-driven architecture 比較複雜，要注意 remote process availability, lack of responsiveness, broker reconnectoin logic

另一個要注意的是缺少單一 business process 的 "atomic transaction"，因為 event processor 互相分散獨立，很難跨越 processors 提供 transaction。

使用時必須持續注意 events 可能無法獨立運作，如果有某些功能需要 undivided transaction，可能就不能使用這個 pattern

最難實作的是 creation, maintenance, governance of event processor component contracts，也就是要統一 event 的格式，建議可以用 XML, JSON, Java Object 等等，並要建立 contract versioning policy

Pattern 分析

• agility: high

  因每個 processor 功能單一，且各自獨立，可快速修改更新

• ease of deployment: high

  decoupled nature of the event processor components

• testability: low

  unit testing 簡單，但整合測試很複雜

• performance: high

  因為都是非同步呼叫

• scalability: high

  每個 event processor 可分別 scaled

• ease of development: low

  因為非同步呼叫，開發困難，不容易做錯誤處理 (unresponsive event processor, failed broker)

References

软件架构入门 - 阮一峰的网络日志

MarTech

MarTech = Marketing + Technology 行銷科技，泛指所有能協助行銷的科技工具與方法。在疫情時代，電商取代了一般店家，是大多數人消費的方式，因為網路及電子化，讓店家要用不同的方法尋找及維繫客戶，也更容易運用資訊科技工具協助行銷。

AMT亞太行銷數位轉型聯盟協會在2022/3發表 MarTech Landscape，由 2021的183項科技工具/服務，成長為277個。協會將工具分為六類：

1. 內容與體驗（Content and Experience）

   部落格文章、SEO、社群貼文、圖片、影片、UI及UX設計等

2. 社群與關係（Social and Relationship）

   客戶關係管理及粉絲互動，協助企業掌握粉絲組成、貼文成效，規劃合適的社群形象及素材

3. 流程與管理（Process and Management）

   財務與預算管理、產品與專案管理、敏捷 (Agile) 與精實(Lean)創業管理與廠商分析等各方面的管理

4. 商業與銷售（Commerce & Sales）

   自動化銷售系統、線上支付服務、聯盟行銷、電商行銷

5. 廣告技術（Advertising and Promotion）

   包含關鍵字廣告、GDN、社群廣告等各種廣告形式，以科技技術精準規劃廣告投放策略，包含投放時間、TA輪廓及廣告素材等，提升廣告投放的成效。

6. 數據（Data）

導入行銷工具的方法

根據打贏電商勝仗：MarTech 工具怎麼選？，企業可透過三個階段的解構，導入適合的工具

• 解構

  拆解 customer journey，從一開始的客戶聯繫到售後服務，為每個階段定義目標及評估指標。ex: 客戶的訪問次數、滿意度調查，社群曝光度、退貨率

• 拆解

  拆解想要的結果，提出對應的策略及方法。ex: 要提高滿意度，要透過網站優化、email 追蹤提升客戶體驗。

• 設計

  訂立主要策略後，就用以下問題尋找適當的工具

  1. 行銷的目的

  2. 是否能整合現有工具

  3. 行銷管道

  4. 使用工具的對象

案例

Martech雙周報第16期：Line臺灣三大Martech應用一次看，靠AI找潛在客群與高價值用戶，更能預測用戶受廣告的影響程度 | iThome

吸引客戶使用特定 Line 服務

1. 蒐集使用任務牆及官方帳號的使用者網路，找出同時使用任務牆及官方帳號，與只使用官方帳號未使用任務牆的使用者

2. 以圖嵌入模型描繪用戶輪廓，將用戶分類。ex: 使用任務牆的官方帳號用戶，累積點數的方法不同，有的透過購物，有的是加好友，有的是閱讀廣告

3. 排序對任務牆有興趣的官方帳號使用者，投放廣告

推廣特定創作者的貼圖

1. 將用戶分類

   • line 貼圖的忠實用戶，一定會買貼圖

   • 默默購買的用戶，廣告反而會影響購買慾望

   • 一定不會購買貼圖的用戶

   • 給一點獎勵或回饋，就可能會買貼圖的用戶

2. 用 A/B Testing 找出類似的用戶，隨機抽取樣本，測試廣告的影響力

3. 針對顧客特徵，搜集過去一個月的歷史資訊，透過顧客對貼圖的瀏覽、購買與使用行為，來描述顧客對於貼圖產品的涉入程度

4. 運用增益模型中的S-Learner進行建模，先將兩組樣本混合在一起，並且建立一個控制變數稱為treatment，以treatment=0或1，來標示該樣本是屬於實驗組還是控制組，再訓練一個單一的分類器，根據用戶的歷史貼圖使用與瀏覽行為，來預測其購買貼圖的機率是多少。透過調整treatment，就能取得一個用戶收到、未收到廣告分別的購買機率，最後將兩個數值相減，則可以得到增益（uplift），得知廣告如何影響一個人的購買意願與程度。

找出高貢獻度用戶

1. 透過用戶的歷史購買行為 RFM，包括最近一次的消費時間點（Recency）、消費頻率（Frequency）與消費金額（Monetary），也就是運用RFM模型，來了解顧客的歷史價值

2. 預測顧客的未來價值，也就是顧客終身價值模型CLV（Customer Lifetime Value）

   • 透過人口統計、瀏覽記錄、購買歷程、官方帳號互動的行為，從中萃取出上百種特徵來進行建模

   • 運用過去450天的資料，來預測一個用戶未來180天內，可能帶來多少價值

References

Martech是什麼？認識6大領域及發展趨勢，規劃精準行銷策略

行銷科技Martech是什麼？企業應如何挑選工具，實現以數據驅動的行銷？ | 天新小學堂｜CRM知識庫

AMT亞太行銷數位轉型聯盟協會

Martech 是什麼？行銷科技崛起！Martech完整解釋與趨勢大公開！

2022年臺灣Martech最新版圖出爐，工具大增5成以數據分析工具暴增最多 | iThome

AMT《2022年台灣行銷科技版圖》出爐 新版數位行銷工具爆發 | 熱門亮點 | 商情 | 經濟日報