1、資料服務設計：
一庫一服or一庫多服：
無論是單體應用，還是微服務應用，有一點是肯定的：應用的各個模組之間都需要進行較為頻繁的通訊，通過一起協同合作，來實現應用的整體價值。在單體應用中，這種通訊是通過方法呼叫來完成的。在微服務中，則通過 api 呼叫來完成。這些模組或者服務間呼叫，大部分時候是為了共享資料。 共享資料最賤的方式當然就是採用一種共享資料庫的模式，也就是單體應用常用的方式 - 應用可以有多個系統模組，但一般都是只有乙個資料庫。
混合持久化：
混合持久化在大型網際網路公司是乙個比較風行的模式，它秉承的原則就是為特別的任務提供最好的工具。比如說某個系統提供乙個高併發低延遲的共享使用者會話方案 (shared session storage)， redis 可能是乙個非常理想的選擇。如果是實現乙個產品目錄，涉及到大量不定結構的商品資料及屬性的建模管理，系統可能會採用模式靈活，動態 schema 的 mongodb 來作為我的資料庫解決方案。如果系統希望支援非常強大的全文搜尋，elasticsearch 則是行業中的佼佼者。
2、資料一致性：一種比較常見的做法就是使用分布式事務來搞定，比如2pc等。但是這種做法對於現代應用來說也許不是一種可行的方案。cap定理要求你必須在可用性和一致性之間選擇，可用性通常是較好的選擇。而且，許多現代技術，例如大多數nosql資料庫，甚至不支援acid事務，更不用說2pc。所以管理資料的一致性需要使用其他的方式。我們使用事件驅動架構中的一種技術叫事件源（event sourcing）來解決分布式事務。
event sourcing （事件源）通過使用根本不同的事件中心方式來獲得不需2pc的原子性，保證業務實體的一致性。 這種應用儲存業務實體一系列狀態改變事件，而不是儲存實體現在的狀態。應用可以通過重放事件來重建實體現在狀態。只要業務實體發生變化，新事件就會新增到時間表中。因為儲存事件是單一操作，因此肯定是原子性的。
3、分布式查詢：實現查詢的好方法是使用稱為命令查詢責任分離（cqrs）的體系結構模式： command query responsibility segregation。如名稱所示，cqrs將應用程式分為兩部分。第一部分是命令側（command-side），其處理命令（例如，http post，put和delete）以建立，更新和刪除聚合。前提是這些聚合是使用事件源實現的。應用程式的第二部分是查詢側（query-side），其通過查詢聚合的乙個或多個物化檢視（materialized views）來處理查詢（例如http get）。查詢側通過訂閱由命令側發布的事件來保持檢視（view）與聚合（aggregate）同步。查詢側（query-side）檢視可以使用任何型別的能滿足需求的資料庫來實現。根據需求，應用程式的查詢端可能使用乙個或多個以下資料庫；在很多場合，cqrs是乙個以事件為基礎（event-based）的綜合體，比如使用rdbms作為記錄系統再使用比如elasticsearch來處理文字查詢。cqrs的查詢側可以使用其它型別的資料庫，支援多種型別的資料庫，不僅僅是文字搜尋引擎。而且，它通過訂閱事件準實時地去更新查詢側的檢視。
系統架構系列（二） 系統架構的目的 難點和方法
在本系列的第一篇文章中已經給出系統架構的公式定義 系統架構 要素 連線 解決特定的問題，本篇文章重點討論應對系統架構的方法。如今，系統架構在業內還沒有定型的固定方法，一般會講 需求分析 系統分析與設計 uml 領域建模 設計模式 軟體工程等，筆者不打算這樣講，這樣下來會有厚厚一本書，希望從簡潔 可落...
的技術難點 模擬電子技術中的重難點解析
以下文章 於電工電氣學習 模擬電子技術是電氣工程及其自動化等專業的學生必須掌握的一門技術，此課程在專業培養計畫中具有舉足輕重的的地位，少年子弟江湖老，如今，走上工作崗位的我們在工作中也許會接觸到這些知識，下面就模擬電子技術中的重難點做一些說明。一 放大電路基礎作為本課程的基礎，由於課程剛入門，概念較...
深度解析原型中的各個難點
本文不會過多介紹基礎知識，而是把重點放在原型的各個難點上。大家可以先仔細分析下該圖，然後讓我們進入主題 首先來介紹下prototype屬性。這是乙個顯式原型屬性，只有函式才擁有該屬性。基本上所有函式都有這個屬性，但是也有乙個例外 let fun function.prototype.bind 如果你...