一致點：統一封裝對外服務爭議點：
一致點：統一封裝sdk對於上述爭議點，會議最終也沒討論出結論來。個人覺得，這兩個爭論點實際上是乙個業務架構問題與技術架構問題，只有把這兩個問題理清楚，才能做出清晰的判斷。爭議點：
業務架構：實際上就是理清各方如何分工，如何互動，如何設計的問題。對於該場景的有兩種架構方式，一種為中控式、一種為並行式。
中控式可理解為由乙個中樞統一控制，大致結構圖如下所示：
核心思路：好處：
難點&弊端：
中臺邏輯複雜化，相容維護成本高，不易迭代
並行式從字面意思可理解為並行設計，兩條路線不衝突，大致結構圖如下所示：
核心思路：好處：
灰度切換方便，影響範圍可控制在較小的業務範圍
無需相容處理，**邏輯清晰，精簡；全部切換後相關**可整體廢棄
難點&弊端：
技術架構：技術實現細節如何做到高內聚、低耦合、易擴充套件、良好的版本迭代與向下相容等，設計思路依賴業務架構。對於爭論點二，有如下兩種技術架構思路，一種為集中相容處理，一種為特定處理。
核心思路：隱藏內部實現邏輯，提供統一的對外出口
好處：
強有力的控制，可做到內部變更對外部無感知
難點&弊端：
事前需要超前規劃，強有力的抽象，需保持克制只提供最小功能集，避免相容問題
核心思路：好處：
元件文件無需單獨編寫，開發人員參考官方文件即可，鼓勵diy，遇到問題自己排查，而不是推給元件提供者
弊端：
1.克制、恰到好處
這條實際上是乙個平衡與取捨問題，不能一點不往將來考慮，但也不能一下考慮得太遙遠，考慮太遠的問題在於前期投入巨大工作量後期可能一點用不上。2.乾淨、利落、清晰
個人在做業務架構時，會更多的考慮什麼樣的架構能夠讓技術架構更簡潔、清晰，便於維護。盡量避免架構設計劃定的框，造成技術實現細節繁瑣複雜。3.低成本，高收益
對於這個問題，幹一件事總成本是相對固定的，對於上面的問題，我更傾向於前期採用低成本，後續真正要切的時候再投入另外的成本。4.清晰而堅定的開頭、清晰而堅定的收尾
選擇了一種架構就應該從上到下保持一致，在一條道上做到最好，避免三心二意，這也要一點，那也要一點，最後幾不像。最後，不同的選擇對應不同的代價；系統架構的難點很多時候不在於如何架構，而在於如何平衡與取捨；蘿蔔白菜，各有所愛。
一場監控平台架構培訓感悟
最近部門安排了一場關於自動化運維體系的系列培訓，開篇培訓就是監控平台的講解，聽完之後很有感觸，在此記錄下當晚培訓的主要知識點以及自己的理解 正文自動化運維體系 首先放上整個運維體系架構 架構最底層就是一些硬體基礎，在硬體基礎之上建立cmdb與web api 對底層做了一次封裝，提供一些操控與獲取資訊...
Discuz NT 系統架構的討論
一 分析 discuz nt 支援2種資料來源，sqlserver和msaccess，但其資料庫訪問層實際上已經支援了 mysql，只是安裝程式還未提供基於 mysql 的。discuz nt採用了 頁面類 業務類 資料庫訪問類 dbhelper 資料庫 這樣的分層方式。資料庫訪問類有1個大介面3個...
一場殊死的戰鬥
在軟體世界中漫遊，往往失去前進方向。在軟體世界裡，許多事情都可以去做，但必須有個 中心 那麼，在我心中，這個 中心 是什麼呢？這些年來，我要幹什麼事情呢？一言以蔽之，linux office。但是，這兩個東西必須是gnu 計畫的產物，必須最終體現軟體的價值 自由使用。軟體的價值，就在於使用。評判是非...