every day is another day!

摘要： 程序員，如果系統突然報了一個空指針異常，你肯定像吞了一只蒼蠅一樣尷尬。 那么如何在日常開發過程中降低NPE？ 問題 回答 現狀 返回空值會出現大量的空指針異常 目的 改進方法的返回值，降低出現空指針異常 實現路徑 方法返回空集合或者空數組 跟我來！ 背景 下面的方法看起來很常見。 private f 閱讀全文

摘要： 作為程序員的你，代碼中最多的就是各種方法了，你是如何對參數進行校驗的呢？ 背景 大部分的方法和構造函數對傳入的參數值有一些限制，比如：常見的索引值必須是非負數，對象引用不能為空。 你應該使用清晰的文檔來標注所有的這些限制，然后在方法體開始的地方強制他們檢查。 應該在錯誤發生的時候盡快的檢查出來，這是 閱讀全文

摘要： 上圖為常見的臺式機，程序員，你看了有啥啟發？ 臺式機生產線 我的maven代碼工程 xxx 顯示器 xxx-web 主機 xxx-app 鍵盤 xxx-domian 鼠標 xxx-infrastration 臺式機 xxx-all.jar 雖然不能完全對應的上，我拿開源的dubbo描述一下我的問題。 閱讀全文

摘要： 上圖為常見的臺式機，程序員，你看了有啥啟發？ 臺式機生產線 我的maven代碼工程 xxx 顯示器 xxx-web 主機 xxx-app 鍵盤 xxx-domian 鼠標 xxx-infrastration 臺式機 xxx-all.jar 雖然不能完全對應的上，我拿開源的dubbo描述一下我的問題。 閱讀全文

摘要： 作為一個程序員，假如讓你繪制當前正在開發的項目的架構圖，你會怎么繪制？ 背景 先來同步一個理念。架構圖的作用是什么？ 我回答一下： 提供了一個簡單的方法給到開發團隊（從開發工程師，測試工程師，架構師，測試，項目經歷，產品經理，交互設計師，用戶）能夠更簡單的描述和溝通軟件架構，讓團隊每個人腦子里的架構 閱讀全文

摘要： 作為程序員的你，能勝任運維的工作嗎？ 背景 那么運維主要解決那些問題呢？ 答：1.部署，但是大部分工作可自動化； 2.維護產線系統穩定； 作為程序員的你，清晰自己的程序如何部署上線非常重要，出問題了才知道如何修復。 作為程序員的你，設計的時候就要規避部署帶來的問題。 作為程序員的你，如果能勝任運維， 閱讀全文

摘要： 背景 作為程序員，跳槽或者被跳槽都是尋常事，那么當你成功入職一家新公司，你會如何快速適應新工作？ 即快速的融入團隊，盡快發揮價值。 按照基本的思考框架。先來思考一下。 思考問題 回答問題 where are we?現狀 剛入職，對業務了解很少 where are we going?目的 快速上手，至 閱讀全文

摘要： 假如我們有一個叫shiny的項目，它是由一個程序Shiny-Server 和一個數據庫 Shiny-DB組成的; 簡單結構圖如下： 但是很多時候，現實開發團隊是這樣的： 我們的項目shiny項目的運行環境是有多套的， 我們擅長解決代碼層面的問題。 版本控制工具git非常普遍而且好用 我們有持續集成和 閱讀全文

摘要： 上圖是一張普通地圖，最刺眼的就是邊界？ 非常好奇地圖繪制工程師是如何描繪如此彎曲多變的邊界的？強制行政區域還是人群歷史原因自然的人以群分？ 我們再換個視角，對工程師或者架構師來說，微服務的邊界如何劃分呢？ 基于DDD設計方法論中的概念 限界上下文 來劃分微服務的邊界； 背景 架構師小李正在團隊推行D 閱讀全文

摘要： 聚合就是歸類的意思，把同類事物統一處理； 聚合根也就是最抽象，最普遍的特性； 背景 領域建模的過程回顧： 那么問題來了？ 為什么要在限界上下文和實體之間增加聚合和聚合根的概念，即作用是什么？ 如何設計聚合？ 按照一般的研究和學習思路，先弄懂概念，然后結合實際例子理解概念，然后再回答提出的問題。 聚合 閱讀全文

摘要： 圖中是一個別墅的模型，代表實體，可以真實的看得到。那么在DDD設計方法論中，實體和值對象是什么呢？ 背景 實體和值對象是領域模型中的領域對象，是組成領域模型的基礎單元，一起實現實體最基本的核心領域邏輯。 那么問題來了： 1， 他兩在領域模型中的作用是什么？ 2，在系統中跟代碼模型和數據模型是怎么對應 閱讀全文

摘要： 圖中是暗黑領域，非常牛逼的技能。 背景 DDD中出現的名詞： 領域，子領域，核心域，通用域，支撐域，限界上下文，聚合，聚合根，實體，值對象 都是關鍵概念，但是又比較晦澀，在開始DDD之前，搞清楚這些關鍵概念名詞非常的重要。 那它們作用體現在哪里呢？ 領域-子領域 領域是： 從事專門活動或者事業的范圍 閱讀全文

摘要： 背景 名詞解釋 如果你的團隊目前正是構建微服務架構風格的軟件系統，問自己兩個問題？ 軟件架構演進 軟件架構大致經歷了從單機架構，集中式架構，分布式微服架構，程序的層次圖如下所示。 單機架構 特點如下： 1， 面向過程的設計方法； 2， 結構為CS； 3，程序的層次分兩層，即UI層和數據庫層； 4， 閱讀全文

摘要： 簡介 scalable open financial architecture stack , 可擴展開放的金融架構棧； github: https://github.com/sofastack/sofa-boot 快速構建金融級別云原生架構的中間件。 特點： 開放，金融級別，云原生； 微服務體系組 閱讀全文

摘要： cola擴展點使用和設計初探 封裝變化，可靈活應對程序的需求變化。 擴展點使用 步驟: 定義擴展點接口，類型可以是校驗器，轉換器，實體； 必須以ExtPt結尾，表示一個擴展點。 比如，我定義一個云樞的組織結構的擴展點接口，消息發送擴展點，二開擴展點，webapi的rest接口擴展點點。 定義擴展點接 閱讀全文

摘要： 導彈攔截，精準防御。 背景 攔截器：在不修改應用程序業務邏輯的情況下，一組基于事件的可插拔的邏輯處理鏈； 類比springMVC的攔截器： 這些都是通過配置攔截器，插入到應用程序中，實現可插拔的修改業務邏輯； kafka在0.10.0.0版本中開始引入攔截器。分為生產者攔截器和消費者攔截器，類似責任 閱讀全文

摘要： 如何設計出核心功能穩定，業務功能不斷擴展的軟件系統，我想到了微內核架構。 定義 微內核架構又叫做插件架構，是面向功能進行拆分的可擴展架構。 比如：Eclipse插件，Linux ； 架構圖 插件管理 插件注冊表機制：名字，位置，加載時機； 插件連接 指的是插件如何連接到核心系統。 插件間通信 插件之 閱讀全文

摘要： 背景 這里的kafka值得是broker,broker消息丟失的邊界需要對齊一下： 1 已經提交的消息 2 有限度的持久化 如果消息沒提交成功，并不是broke丟失了消息； 有限度的持久化（broker可用） 生產者丟失消息 這個發送消息的方式是異步的；fire and forget,發送而不管結果 閱讀全文

摘要： 背景 保證kafka高吞吐量的另外一大利器就是消息壓縮。就像上圖中的壓縮餅干。 壓縮即空間換時間，通過空間的壓縮帶來速度的提升，即通過少量的cpu消耗來減少磁盤和網絡傳輸的io。 消息壓縮模型 消息格式V1 kafka不會直接操作單條消息，而是直接操作一個消息集合。 消息格式V2: 1, 抽取了消息 閱讀全文

摘要： 背景 kafka如何支撐海量消息的集中寫入？ 答案就是消息分區。 核心思想是：負載均衡，采用合適的分區策略把消息寫到不同的broker上的分區中； 其它的產品中有類似的思想。 比如monogodb, es 里面叫做 shard; hbase叫region, cassdra叫vnode; 消息的三層結 閱讀全文