這是四年前倫敦一個技術大會上的一場非常獨特的分享，沒想到一場技術大會上能有這么幽默的另類架構師，作者以反諷的形式舉出了 10 個微服務環境下對系統搞破壞的 tips。我看了很多遍，其中的案例其實日常研發中大部分也都遇到過了，之前也總結過各式各樣的吐槽，比如之前寫的《中臺的末路》《微服務的災難》《MQ 正在變成臭水溝》等等。希望日后自己也能做類似風格的演講。

下面是演講的內容：

開場白，先是免責聲明，讓人對號入座就不好了：

disclaimer

然后是聽眾收益：

acquirements

老板想要搞事情，讓公司系統更現代化，你不想這么干，得找點理由反駁他；或者你想破壞你們現在的系統；學習從實踐中總結的血淋淋教訓；具體案例做過了匿名化處理，讓罪犯可以稍微心安理得一些。

老板從網上學到了新詞匯，比如工業4.0(哪個營銷號說德國人不講工業4.0來的？)；云 + 敏捷就是牛逼；Extreme agile cloud native digital microservice 聽著就非常 modern。

然后把這個政治任務交給了 IT 人員，你們來干吧，我們全都要。

搞 IT 的還是要面向老板服務，一通調研，總結了微服務的特性：

microservices

靠，太復雜了，還是看貓片更輕松愉快哦！

cat

這后面舉的例子，都可以用來給你的系統搞破壞，按照 awesome 度的排列是 10 -> 1 越來越 awesome。

awesome

10 - Go Full-Scale-Polyglot

polyglot 英[?p?liɡl?t] 美[?pɑ?liɡlɑ?t] adj.?通曉(或使用)多種語言的;?用多種語言寫成的; n.?通曉多種語言的人; [其他]?復數：polyglots

這是早期微服務吹的最多的多語言優勢，你可以用合適的語言重構系統的任意一部分。這里推薦更激進的方式，最好把所有的技術棧全用上：

techzoo

有種類繁多的前后端技術棧，有種類繁多的各式打包工具，最終形成多彩的科技動物園：

• 學到了技術知識，技術人員很開心

• 可以用各種語言把同一個輪子造一萬遍，好開心

• 碰到了技術棧的問題(如 React 的 Bug)，還能去逼著 Facebook 的人來修問題，很酷

• 還可以搞出類似量子物理中的 Heisenberg monitoring 的問題，線上沒法監控，開心

讓系統有更多 risk 這樣才能更有趣。這里我們說的 polyglot 有時也被人戲稱為 polywtf。當然從另一些方面來講：

• 自由是人權的一部分

• 每個人都喜歡解 puzzle - 我們可以有各種不同風格的接口，比如 REST，HAL，SIREN，這樣人們在接入你的系統的時候就不太搞得清楚你到底在用什么玩藝兒

• 程序員們都喜歡通過在 stackoverflow 上搜結果的時候交朋友

• 我們可以用各種各樣的 UI 組件，并且應該多嘗試那些 beta 特性

• 讓運維們忙起來，可以用各種多樣的監控和打日志方式，比如你還可以搞自己特別的日期格式，比如用中文來寫日期，這樣大家就都看不懂了

9 - The data monolith

share

分享是一種美德，我們讓所有的系統都接入到一個 DB2 的數據庫里。比如讓 Account 和其它兩個服務的數據庫完全放在一起，這樣大家都可以很高性能地讀取各種數據。

這時候 Account 突然要把用戶名從 VARCHAR(50) 改成 VARCHAR(200)，這時候 Credit 服務炸了：

boom

很酷，這樣簡單的方式就可以搞成一團糟。

• 分享是很棒的事情

• 所有微服務都應該共享數據庫

• 不要讓你的表或者 schema 歸某個服務或者某個團隊來管理

• 保留那些潛在的依賴，比如每晚都把大家吵醒的連接池什么的

8 - The event monolith

Event Sourcing 是個完美的市場營銷概念，同時可以解決很多問題：

• 修訂記錄 - 完全無成本的不可變歷史

• 分布式數據管理

• 用 CQRS 給微服務解耦

• 還有很多其它優點

這時候我們的 Account 服務需要把 country 改成一個 free text 字段，因為以前的 code 沒法滿足當前需求了。

比如這里消息中的 country 字段需要增加特殊判斷，那么我們在每個服務中都需要額外增加：

unless?ISO.is_country_code(cnt)?do ... end

WET 的意思是 we enjoy typing，DRY 是過去老掉牙的理念了。微服務是一個很好的借口來讓我們 copy && paste 代碼。所以說 Wet is the new DRY，比如像 netflix 這樣的公司，有成千上萬的服務，我們可以把代碼拷得到處都是，修 bug 的時候也需要修一大堆，這樣就可以打一堆字了，開心。

• 不要修改過去亂七八糟的 event

• 不要想什么數據管理策略

• 把補償動作代碼復制粘貼一下就可以解決問題了啦

• 我們 event history，什么時候都能修 bug

• 要是有人說我們這么個小系統，為什么要 event sourcing？那你只要回復他，我們哪天說不定就長到 Google 或者 linkedin 的規模了呢，萬金油哦

7 - The Home Grown monolith

“If you wish to make MICROSERVICES from scratch, you must first create a FRAMEWORK” – Carl Sagan (slightly paraphrased)

大家都喜歡造框架。

這里我們在公司內造了一套 event sourcing 的框架，每個需要發消息的系統都要接入這個 event sourcing 框架。

evid

有一天，我們突然要做個 breaking change，看起來消息里的這個 id 之前沒啥用，我們就稍微修改一下，把原來的數值變成字符串吧。這個也不需要什么設計，畢竟設計這種事，我們敏捷信徒是從來不干的。

evid2

線上跑了一下，臥槽，炸了：

boom2

這種事件叫 Change the world event，既然產生了，那就得讓所有的依賴服務升級 V2 來兼容這個升級。

微服務承諾各個服務可以并發開發和上線，不過現在我們有了這么個公共的框架，那他們還是得等框架開發完，才能一起上線。

• Cross-cutting 依賴可以作為一種社交工具

• 我們做這些侵入式的框架還是一種對工作崗位的保障

• 寫框架實在是太開心了，一定要多嘗試

• 如果你沒啥思路，這里給你推薦一些 ideas：Collections, String-Utils, Logging, ORM!

6 - Think of the meat cloud

在當前的微服務場景下，所有微服務都是通過 CI 流程上線了。

不過完全自動化的環境是沒有靈魂的，handcrafted 工作才能體現出你的 love。

運維人員都很喜歡 vi，vi 非常棒，各種令人匪夷所思的命令。我們用自己的愛來修改 nginx 的配置的時候寫出了下面這樣的配置：

location?/custmoer?{ }

這個錯誤只在線上犯，而在線下 test、staging 環境均不存在，這樣只有在客戶那里才會炸。這樣和客戶發生了溝通，非常的 social，在星期天休息日和客戶溝通非常的開心。

• 以手動維護為榮耀。

• microsoft word 也是一種形式的自動化。

• 如果有人 diss 你，你就搬出：我們又不是 Google，不需要那么復雜的基礎設施

• 如果有人問我們怎么做 LB 什么的，那我們直接說用 docker，因為 docker 可以掌管一切，LB，Security 什么的，你一說 docker 他們就跑了

5 - The distributed monolith

服務之間互相調用，級聯調用，就像親密無間的朋友：Friends　stay close together。

Credit --> Account --> Customer --> Security

Credit 需要 Account 的數據，Account 需要 Customer 的數據，Customer 需要 Security 提供的安全特性。多重依賴，只要末端服務故障，整個服務一起撲街。只要 Security 掛了，大家一起完蛋。

The Musketeer Pattern

這種形式完美地結合了微服務的復雜性以及單體的脆弱性，是 shortest way to success。

• 網絡超級可靠的

• 依賴越多，說明設計的越好，因為大家都在談 dependency injection 啊

• 同步的依賴就更棒了

• 能服務一部分請求也比掛了強啊，不要熔斷了

4 - The SPA monolith

前端 UI 直接對接所有后端服務，因為我們的后端服務要 micro 啊，只要讓前端 big 就行了。

bigui

現在要加個什么字段檢驗，邏輯要加到哪里？無所謂了，隨便能找地方塞進去就行了。

• 這樣我們前后端也沒啥明確的業務職責劃分，我們就可以開會來討論職責和各種彼此沖突的 feature 了

• 同時還能因為各種 side effects 讓 tester 們忙起來，tester 也是要吃飯的，大家都開心

• 要是發生了什么失敗，非常容易找，反正就在那一坨 UI 里面

盡量別用組合，我們這樣的大 UI 已經夠了呀，也別用超鏈來關聯，我們這樣就夠了。

3 - The decision monolith

都 2017 了，快上 Java 7 吧。

同事們想嘗試新技術，我讓他們準備 PPT 來說這東西有多好用，哈哈，好開心。

• 這樣可以讓那些積極的同事受挫

• 如果你已經超過 30 了，還可以這么說：這是企業級開發，小朋友

• 象牙塔很美哦，你見過么？

• 別人都是 SB，只有你最聰明

2 The monolithic business

業務人員也不知道你們的技術架構是啥樣的，反正有需求么就拉會，有變更么就管理，這樣就有了 Change Management，有 Requirement Management，這兩樣都是瀑布開發的好朋友啊。

• 只要工作慢，我們就有更多的時間刷 Twitter 了

• 只要為多個老板工作，我們就是個自由人，某個老板來找，我們只要說正在為其他老板工作就好

• 變更和需求管理是你的朋友

• 那些業務人員又不懂 Eric Evans

• Conway 定律我們還可以反著用哦

1 - Use a HR driven Architecture

直接找一個會 React 的人比找一個軟件大師來還是容易多了。

讓前后端協作太順暢也不行，最好在前后端里建起一堵墻，這樣在墻中間就能填上各種 project manager，讓他們在團隊間互相傳話。有需求聽不懂？直接轉給另一個團隊就可以。

• 我們程序員討厭除了自己以外的所有其他人

• 要避免知識的傳播

• 業務人員懂業務，技術人員懂技術

• 沒有人應該知道企業的業務大圖，最好都在黑暗中工作

• 開會還是很開心的，雖然我不喜歡人，但是開會的咖啡和零食還是不錯的

要是工作中出 Bug 了怎么辦，隨時指責別人啊，因為：

It’s always the other team’s fault!

總結：

所有的失敗都是因為隱藏在背后的某種單體：

• Data

• Frontend

• Framework

• Deployment and Release

• Process，比如隱藏在 Agile 后面的 waterfall

microservice 表示更多的工作，我們需要與之抗爭。

用各種 it's too difficult，we can't do it 的借口

多想想組織架構上的影響，不想改變。還是擁抱單體架構吧。

微服務是垃圾，坐等 SOAP 4.0

不要低估破窗效應，我是個 developer，我什么都能給你破壞掉

[1]?原視頻鏈接[1]

[1]

1] [原視頻鏈接:?https://www.youtube.com/watch?v=X0tjziAQfNQ&feature=youtu.be

總結

以上是生活随笔為你收集整理的在公司的微服务上搞破坏真是太开心了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。