1、可復用構件應具備哪些屬性

可用性：構件必須易于理解和使用。

質量：構件及其變形必須能正確工作。

適應性：構件應該易于通過參數化等方式在不同語境中進行配置。

可移植性：構件應能在不同的硬件運行平臺和軟件環境中工作。

可變性(Variability)：構件應能針對不同的應用系統，只需對其可變部分進行適當的調節等

2、王工：客戶端——web服務器——數據庫服務器；

李工：客戶端——web服務器——多應用服務器-數據庫服務器

3、O/RM的含義及優點

O/R映射指的是對象/關系映射，是一種編程技術，將關系數據庫中的關系型數據與面向對象編程語言中類型系統定義的 數據進行格式轉換。

三點好處：

(1)可以將業務邏輯與數據邏輯分離。

(2)可以使得開發人員采用面向對象的方式訪問底層關系型數據庫。

(3)能夠做到上層應用與底層的具體數據庫無關，兩者解耦合。

4、影響Web應用系統性能的三個主要因素：

(1)數據庫的連接與銷毀。可以采用數據池的方式緩存數據庫連接，實現數據庫連接復用，提高系統的數據訪問效率。

(2)構件或中間件的加載與卸載。可以采用分布式對象池的方式緩存創建開銷大的對象，實現對象復用，用以提高效率。

(3)線程的創建與銷毀。可以采用線程池的方式緩存己經創建的線程，提高系統的反應速度。

提高數據訪問性能：

5、傳統分層架構與SOA架構區別

6、基于SOA的企業集成中的“數據整合——信息服務”

(1)聯邦服務(Federation,Service)：提供將各種類型的數據聚合的能力，它既支持關系型數據，也支持XML數據、文本數據和內容數據等非關系型數據。同時，所有的數據仍然按照自己本身的方式管理。

(2)復制服務(Replication,Service)：提供遠程數據的本地訪問能力，它通過自動的實時復制和數據轉換，在本地維護一個數據源的副本。本地數據和數據源在技術實現上可以是獨立的。

(3)轉換服務(Transformation,Service)：用于數據源格式到目標格式的轉換，可以是批量的或者是基于記錄的。

(4)搜索服務(Search,Service)：提供對企業數據的查詢和檢索服務，既支持數據庫等結構化數據，也支持如PDF等非結構化數據。,　

7、SOA架構設計的注意事項

當基于SOA來構建一個企業級的系統架構時，一定要注意對原有系統架構中的集成需求進行細致的分析和整理。而關于系統中最重要的元素，也就是SOA系統中服務的構建有兩點需要特別注意的地方：

①是對于服務粒度的控制；

②是對于無狀態服務的設計。

8、針對每條SQL語句都建立索引的不合理原因：

①如果建立索引不當，數據庫管理系統將不利用已經建立的索引，而采取全表掃描。

②當更新操作成為系統瓶頸時，因為每次更新操作會重建表的索引，則需要考慮刪除某些索引。

③應該針對不同應用情況選擇適當的索引類型。例如，如果經常使用范圍查詢，則B樹索引比散列索引更加高效。

④應該將有利于大多數據查詢和更新的索引設為聚類索引。

⑤需要對建立的索引進行實際的測試，因為索引的使用是由數據庫管理系統(數據庫優化器)決定的。

9、SQL優化的基本策略：

①建立物化視圖或盡可能減少多表查詢。

②以不相干子查詢替代相干子查詢。

③只檢索需要的列。

④用帶IN的條件子句等價替換OR子句。

⑤經常提交COMMIT，以盡早釋放鎖。

⑥避免嵌套的游標(Cursor)和多重循環等

10、微服務的優缺點

微服務優點：

（1）每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。

（2）微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。

（3）微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。

（4）微服務能使用不同的語言開發。

（5）去中心化。每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫。

?微服務缺點：

（1）很難在不采用分布式事務的情況下跨服務實現功能

（2）測試工作更加困難

（3）跨服務實現要求功能要求團隊之間的緊密協作

（4）部署復雜

微服務架構的涵義和關鍵原則

微服務是一種軟件開發技術，是面向服務的體系結構（SOA）架構風格的一種變體。微服務將應用程序構造為一組松散耦合的服務，微服務中單個應用程序由許多松散耦合且可獨立部署的較小組件或服務組成。

微服務風格的關鍵原則：

1. 每一個 URI 代表 1 種資源

2. 客戶端使用 HTTP Web 表示操作方式的動詞對服務端資源進行操作

3. 通過操作資源的表現形式來操作資源

4. 資源的表現形式是 XML 或者 HTML

5. 客戶端與服務端之間的交互是無狀態的，客戶端每個請求必須包含理解請求所必需的所有信息

11、網關的主要作用

1、提供統一入口

2、可以進行權限身份認證等安全管理

3、可以根據流量進行限流

4、數據緩存

5、性能監控等

6、異常重試

7、服務降級

12、ATAM架構評估方法的主要過程：

描述和介紹階段：描述ATAM方法，描述業務動機，描述架構

調查和分析階段：確定架構方法，生成質量屬性效用樹，分析架構方法

測試階段：討論場景和對場景分級，分析架構方法

最終階段：描述評估結果

13、數據結構優化

設備信息（設備標識、登記標識、所屬用戶、設備狀態）

設備心跳（設備標識、最后一次心跳時間）

設備異常（設備標識、異常類型、異常發現時間、是否推送）

問題1. 設備與用戶間存在多對多的關系，如單個設備既屬于社區安防用戶，又屬于消防站監管。

問題2. 設備狀態屬于設備動態屬性，不應與靜態屬性混合存儲，會增加靜態信息表的IO。

問題3. 設備心跳不應只存儲最后一次，無法獲取全部設備狀態。

問題4. 設備異常的推送是否僅單一一個用戶一次，如果存在多條推送，則存在一對多的關系。

14、使用MySQL作為數據庫，而軟件研發團隊的架構師卻提出要使用由MySQL、HBase和Redis組成的多種多組數據庫。請給出適當建議。

技術總監的建議中，MySQL屬于關系型數據庫，實際應用中一般用來作為操作數據存儲。研發架構師提出的HBase和Redis屬于NoSQL，實際應用中一般用來做大數據量和高即時性數據存儲。該案例屬于物聯網應用，建議增加NoSQL數據庫提高數據存儲的容量和即時性。

但是HBase屬于列族數據庫，不便于關聯數據的查詢，既降低查詢速度，又增加IO操作，建議采用MongoDB替換掉HBase。