**微服務架構的優劣勢及影響
微服務架構是一種從soa架構演化過來的新型架構。微服務架構具有許多優點。例如在微服務架構中每個服務都有其自己單獨的資料庫，能夠單獨部署，並在其自己的程序中執行而互不影響等。微服務架構的這些優點使得它更適合網際網路公司敏捷開發、快速迭代版本。
傳統架構，也就是單體式應用的所有業務模組都會在乙個專案中開發，並最終打包成乙個war部署在tomcat上。傳統架構是一種很自然的架構，非常適合個人和小團隊開發。但傳統架構也存在著許多問題。首先是耦合度太高，它的處理請求的所有邏輯都在乙個程序中執行，乙個模組出錯會影響到其他模組。其次，每一次對應用程式進行修改都需要重新編譯和部署整個程式。並且隨著專案功能的逐漸增大，應用程式會變得越來越龐大，以至於企業敏捷開發和部署都舉步維艱。同時，傳統架構也因**衝突問題，不適合中大規模團隊開發。
soa架構也是基於分布式架構演變過來的。soa架構意為面向服務。它將共同的業務**抽取出來，提供給其他介面呼叫。服務與服務之間採用rpc遠端呼叫技術。它的特點是底層基於soap或者esb實現，底層使用http或者https+xml資料交換格式實現。soa架構也具有許多不足的地方。首先是它依賴於複雜的中心化服務發現機制。其次soa架構採用soap協議，而soap中xml傳輸協議比較占用寬頻，報文有大量冗餘資料，不適合高併發開發。最後，soa架構服務管理混亂，缺乏服務管理，帶來了管理上的不便。
微服務架構也從soa架構演變過來。在微服務架構種，每個服務只負責非常明確、獨立、簡單的任務處理，並將處理結構以api的形式返回給外部。從實踐的角度來看。微服務時對整個軟體平台或專案的細粒化拆分，拆分後的所有微服務獨立執行，互不干擾。每個微服務都執行在獨立的容器中。
因為微服務架構比soa架構在粒度上更加精細，所以更能讓專業的人更加專注做其專業的事情。同時服務與服務之間採用http協議+json資料傳輸格式通訊。
微服務架構的優勢在於，首先通過分解巨大的單體式應用為多個服務的方法解決了單體式應用過於龐大的問題。在功能不變的情況下，單體式應用被分解為多個可管理的分支或服務。每個服務都有乙個用rpc或者訊息驅動api定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模組化的解決方案，由此，單個服務很容易開發、理解和維護。
其次，微服務架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供api服務。
再次，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。ui團隊可以採用ab測試，快速的部署變化。微服務架構模式使得持續化部署成為可能。
最後，微服務架構模式使得每個服務獨立擴充套件。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬體。
微服務架構也像任何其它科技一樣有不足之處。微服務架構應用是分布式系統，由此會帶來固有的複雜性。開發者需要在rpc或者訊息傳遞之間選擇並完成程序間通訊機制。更加嚴重的是他們必須寫額外**來處理訊息傳遞中速度過慢或者不可用等區域性失效問題。相對於單體式應用中通過語言層級的方法或者程序呼叫，微服務架構下這種技術顯得更複雜一些。
第二個關於微服務的缺點來自於分割槽的資料庫架構。商業交易中經常需要同時給多個業務主體更新訊息。這種交易對於單體式應用來說很容易，因為只有乙個資料庫。但在微服務架構應用中，則需要同時更新不同服務所使用的不同的資料庫。使用分布式交易並不一定是好的選擇。最終，開發者不得不使用乙個最終一致性的方法，從而再一次對開發者提出了更高的要求和挑戰。
第三個缺點，測試乙個基於微服務架構的應用是一項很複雜的任務。對乙個單體式應用來說，要測試它的各種介面功能是很容易的事情。而微服務架構的應用來說，乙個服務可能與許許多多的其它服務相關。因微服務架構而帶來的複雜性有時候會遠超想象，並給測試工作帶來非常繁重的工作量。
第四個缺點是微服務架構模式下應用的任何修改可能存在波及多個服務的風險。比如，假設你在完成乙個案例，需要修改服務a、b、c，而a依賴b，b依賴c。在單體式應用中，你只需要改變相關模組，整合變化，部署就好了。對比之下，微服務架構模式就需要考慮相關改變對不同服務造成的影響。比如，你需要更新服務c，則需要考慮更新對所有依賴於c的服務的影響。
最後，部署乙個微服務架構應用也很複雜。乙個微服務架構應用常常由大量服務構成。例如hailo有160個不同服務構成，netflix有大約600個不同服務構成。每個服務都有多個例項。這麼多例項單純靠人工的力量來監測是非常費時費力的一件事。因此成功部署乙個微服務架構應用需要開發者有足夠自動化的控制部署方法。
目前微服務架構盡在一些中大型公司裡得到了事件，還沒有完全被中小型企業接受。由於微服務架構的優勢，給相關行業帶來的將不只是軟體開發管理上的影響。
微服務架構的靈活性可以使專案的開發國產更易於管理，從而大幅提公升專案開發團隊的開發效率。微服務獨立性、分外分割的設計四象可以使開發人員更加關心元件內部構造，從而提高**質量。同時，服務的復用使得開發人員從以往的**、物件、模組復用種解脫出來。服務復用真正實現了「一次部署，無限使用」。這將使企業在構建後續功能時，大幅降低人力和時間成本。同時，微服務架構的出現使得初創專案的軟體開發可以遵循由中心到外圍，由重要到次要的次序，降低因需求臨時變動帶來的對專案整體性的衝擊，加速專案的形成。另外，隨著微服務開發者的增多，越來越多開發者願意將自己開發的微服務開放給全網使用者進行使用。
#1樓 2019-04-16 19:33 | 金石軟體
在二維線性可分情況下，支援向量機和線性回歸有什麼區別
答：在二維線性可分的情況下，最明顯的差別是支援向量機與（狹義上的）線性回歸的損失函式不同。支援向量機是要最大化支援向量與分介面之間的距離。而線性回歸是要讓總體誤差最小。
其次，支援向量機只考慮支援向量，線性回歸考慮所有的資料。
最後用線性回歸做分類，可能會因初始狀態、步長等因素出現多個結果（梯度下降法）。支援向量機能確定唯一分割面。
顯然支援向量機具有更好的泛化能力。
支援向量機與邏輯回歸（廣義線性回歸）上的區別在於：首先也是損失函式不同。邏輯回歸是交叉熵損失函式。
支援向量機只考慮支援向量，邏輯回歸考慮所有的資料。這一點也是一樣的。
邏輯回歸產生的是概率，支援向量機不是。
邏輯回歸是引數模型，支援向量機不是。
支援向量機自帶結構風險最小化（損失函式中帶正則項），邏輯回歸則是經驗風險最小化。
普遍來說當資料較少時使用支援向量機比較合適，資料較多時使用邏輯回歸比較合適。
軟體體系結構 軟體體系結構概論
開學到現在我已經上了三節軟體體系結構的課程，現在我想把自己學到的整理歸納一下。此篇隨筆對應於教材軟體體系結構概論一章。首先談一談我剛接觸這門課程是的感受。那就是 我靠 軟體也會有體系結構？以前只學過資料結構 演算法 基本的程式語言，覺得程式設計無非就是使用者給我需求，我便按照需求來程式設計序就好，從...
軟體體系結構
軟體體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件 資料構建 連線構建。處理構建 負責對資料進行加工 資料構建 是被加工的資訊 連線構建 把體系結構的不同部分組合連線起來 1 作為通訊的手段 2 代表了早期的設計決策結果 3 高層次的設計復用手段 1 軟體體系結構是風險承擔者 又稱涉...
軟體體系結構 軟體體系結構複雜性
複雜性具有不同的種類和形態，一種簡明的度量是類之間通訊路徑的數量，通訊路徑是類之間存在的持久或暫時連線。複雜性存在四種維度的解釋 從適應能力的角度，認知複雜性度量可以增強可理解性質量，結構複雜性可以增強可維護性和可伸縮性質量。這兩種度量是有關係的，對於低結構複雜性，認知複雜性的較小值雖然是必要不充分...