從微服務聊起

1，微服務，SOA，模塊化，面向對象，DDD……其實是同一個概念

這個概念的核心是組件化。通過這些概念的具體操作，最終實現搭積木式的開發。目的是提升開發效率，降低維護成本。

2，微服務，SOA，模塊化，面向對象,DDD……是同一概念在不同方面的應用

OO是基本單元，模塊化是稍微大一點的單元，SOA和微服務在系統層面。但其實沒有差別，OO是小一點的系統，系統是大一點的對象，本質上沒有區別。

3，深入了解面向對象

在基本的面向對象中，只有兩個概念：封裝，通信。分別決定了對象內部和外部的規範。封裝屏蔽了「積木內部性」，通信決定了「積木和其他積木的互動關係」——但是常常被忽視的一點是「積木和非積木的關係」——在OO編程中常常體現為對象和容器的關係。

在一些容器中的對象池，大概就是類似的關係：容器會透明的為一個service提供一個對象池，對外是透明的，提供高可用服務。

在SOA中非常強調的服務治理，大概是類似的概念。

4，微服務，SOA，模塊化，面向對象,DDD……的誤區

很多人常常將微服務理解為拆分，以為拆分了，走服務了，就微服務了。

但，你將一坨屎劃分成十塊，他依然是屎。

你將一坨難以治理的系統拆分成很多個看起來簡單的小系統；近看每個系統都簡單了，遠看依然一模一樣——同時降低協作和運行效率。

微服務 OO……真正有效做法不是拆分，而是機制和抽象。

5，溯本追源

這些概念是是隨著軟體複雜度問題而產生的解決方案，方案的核心思想就是組件化，積木化。在不同方面展現出來的具體手段就是SOA，模塊化，面向對象。是佛之諸相，程序員要做到見諸相非相。

除了這些具體化的可見性操作以外，解決軟體複雜性的手段還有：

結構上的分層分塊（MVC，三層模型，……）

業務上的分層分塊（商城，支付，賬務……）

問題層次上的分層分塊（DDD——業務和技術分離；這個比較形而上，偏向思想，難以具體化，所以不像前面幾個容易落地）

以上種種方法，不過分析法而已，會將一個大問題劃分成幾個小問題分別解決。但是同時會造成碎片化。

解決碎片化的方法是抽象和機制

你要所有碎片化的小問題進一步抽象，找出更通用的解決方案，同時解決這個單元和其他單元集成的最簡單的機制。

舉個例子：grep aaa bbb|grep ccc|......

1，抽象：如果grep做不到對任意文本文件搜索，只能搜索txt，或者crv，玩不下去

2，抽象：如果linux不是任意io都是文件，這裡玩不下去

3，機制：如果沒有標準std in error這個基本機制，玩不下去（pipe將stdout轉stdin）

布置個小作業：

1，怎麼增強grep，可以任意文件，doc，ppt，二進位。

2，了解一下powershell和bash不同的抽象機制

如果你設計的組件M能解決這塊領域所有的問題，並且找到作用於很多好的和其他模塊這塊問題的方式。那麼就可以實現簡單的開發配置就能彼此增強。而不需要每次都針對特例編程。

你得明白，解決複雜性的辦法是怎麼良好的抽象設計，微服務解決的是分布性性能提升。而多數人為什麼選擇微服務去解決複雜性問題——用技術方案去解決設計問題!？

微服務唯一能提升的是分布性可擴展。對90%的系統而言。還遠沒到考慮這個問題的時候。

這時候帶來的問題只能是複雜性依然無解，而開發效率大幅降低。