今天我研究的課題《三層架構，如何提高協作開發和聯調效率》，作為一名剛走出校園應屆生，這一課題對我來說是即陌生又熟悉，對於三層架構的誕生、理論和優缺點，往深了講，是我在校園和往期實習工作中尚未接觸到的深水區，然而在當前重構專案中我卻又是其中的一名實踐者——業務層開發人員。半年來的實踐與開發，在架構師的帶領下，摸著石頭過河，在今天這個課題下，寫下我對三層架構的思考與提高聯調的解決方案。本人才疏學淺，深知在後端開發領域知識面不夠深不夠廣，對於課題寫下自己的一點想法。
三層架構(3-tier architecture) 通常意義上的三層架構就是將整個業務應用劃分為：介面層(user inte***ce layer)、業務邏輯層(business logic layer)、資料訪問層(data access layer)。區分層次的目的即為了「高內聚低耦合」的思想。
三層架構.jpg
通俗來講就好像小朋友玩的積木一樣，有一天，小朋友(客戶)哭著要乙個汽車玩具(介面層)，無奈家境一般，為了滿足孩子的願望，父親就想了個辦法，買了很多積木玩具塊回來，媽媽按照汽車組裝步驟圖(業務層邏輯層)組裝乙個個積木塊(資料訪問層)最後變成了乙個汽車玩具，因為小朋友(客戶)的需求是千變萬化的，五彩斑斕的黑五光十色的白都有這麼乙個可能性，哪天哭著鬧著要個飛機玩具那也是合情合理的，但回歸底層，還不都是乙個個小小的積木(資料庫)，世界上最不會變的那就是變化了，在客戶第一的前提下，三層架構的提出是很重要也是不可或缺的。
三層架構-積木模擬
很明顯，重構後對於整個專案一切都是可觀的，優點顯而易見，缺點也不可忽略，重構後的優點:
1、結構清晰、耦合度低；結構更加的明確，可以降低層與層之間的依賴；開發人員可以只關注整個結構中的其中某一層；
2、可維護性高，可擴充套件性高；可以很容易的用新的實現來替換原有層次的實現；有利於標準化；在後期維護的時候，極大地降低了維護成本和維護時間
3、利於開發任務同步進行；容易適應需求變化，利於各層邏輯的復用。
重構後可能面臨的問題點:
1、降低了系統的效能；這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改；這種修改尤其體現在自上而下的方向。如果在介面層中需要增加乙個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的**。
3、增加了開發成本；這點是毋容置疑的事情，在人員上，本來需要兩隊人馬完成的事情，現在需要三隊人馬；在時間上，**聯調，兩個節點聯調介面，需要的時間相比之前提高了。
然而公司重構專案從去年春節啟動後到現在已有半年時間，在參與重構專案的開發過程中無疑是「不知廬山真面目，只緣身在此山」，持續不斷的投入到業務開發和工作中，臨近專案期末，現跳出圍城進行知識上的擴充套件與昇華，給出個人在參與專案過程中的一點思考與改進。
只有充分思考我們在實施專案的過程中的客觀存在的問題，我們才能理性並合理的提出解決方案，我覺得有以下難點問題：
1、在需求不明確的情況下，產品和開發人員並行工作，產品輸出遠小於開發進度，從源頭開始輸入量小，下流前期輸出量不多，拖到後期就導致功能開發緊張 。例如：到7月1號截止，優惠券活動審核的列表原型未出。
2、排查問題，怎樣查能快速定位，找到原因，避免消耗人力過多。例如：前端說登陸不了，報系統錯誤，如何準確定位，解決問題。
3、前端、業務層、微服務三層架構中各層應用元件和技術相對前沿，在技術方面遇到的技術難點需要時間驗證。例如：業務層在重構期間，經常出現模組節點掛的情況，經多次修改基礎**，各個模組均需要同步修改後的**，消耗了一定時間。
4、頂層設計，錯誤碼，子系統間銜接呼叫要先設計好。我們現在有但還不完美。
5、三層開發人員統一的開發進度規劃，不能統一時間開發，當成流水線來安排。
產品同學：
1、需求必須明確，反覆確認需求細節，真正理解需求和內在價值。
2、確認需求後需要確認關聯人員的開發時間點，按照緊急程度，精確到天或小時。
開發同學：
1、自測：業務層和微服務自測一波再給介面，不要那麼隨性地就將開發中的介面丟給前端。
2、溝通：在自測過後的介面來進行聯調本來就存在出錯的可能性，例如：資料錯亂、請求頭為空等情況，聯調出錯是一種非常正常的情況，在聯調過程中，大家一定要戒驕戒躁，相互理解，及時溝通，積極反饋。由測試同學做主推動，逐層反饋，落實責任人，給出期望完成時間，問題責任人完成後反饋。
3、log日誌：主要以業務層的報錯與警告來解決問題，目前業務層規範了log日誌輸出，在測試同學介面報錯的情況下，定位到某乙個微服務的報錯和報錯原因。但不可避免的需要人力的排查問題所在。
c mysql三層架構例項 三層架構例項
一 概要 這篇部落格，準備用乙個小demo來介紹應該實現三層架構。三層架構只是分層的一種經典形式，到底分幾層，要依具體情況而定，考慮到系統的複雜程度，和後期的可維護性，完全可以分四層，五層，甚至六層，七層。二 demo 1 實現語言 vb.net 2 需求 學校機房收費系統 中的乙個功能 操作員為學...
三層架構 之三層擴充套件七層
哎，真心不想在這裡寫這篇部落格，本來三層到七層頂多了也就用兩天時間去分析，結果我用了將近四天，最後我都快崩潰了，還有好多問題都是同學幫我找出來的，真是很是汗顏吶！下面是我三層架構擴充套件成七層架構的uml包圖 之前看別人都是用的vb.net版，我就覺得剛學習了c 語言，就先用c 版吧，結果倒好，兩種...
三層架構 UI BLL DAL
通常意義上的三層架構就是將整個業務應用劃分為 表現層 ui 業務邏輯層 bll 資料訪問層 dal 區分層次的目的即為了 高內聚，低耦合 的思想。表現層 ui 通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。業務邏輯層 bll 針對具體問題的操作，也可以說是對資料層的操作，對...