需要掌握知識點：
（1）vo（view object）：檢視物件。
用於展示層，它的作用是把某個指定頁面（或元件）的所有資料封裝起來。
（2）dto（data transfer object）：資料傳輸物件。
主要用於外部介面引數傳遞封裝。公開給別人可以看到的一些字段
（3）do（domain object）：領域物件。
主要用於運算元據庫層傳遞。就是從現實世界中抽象出來的有形或無形的業務實體。
（4）po（persistent object）：持久化物件。
它跟持久層（通常是關係型資料庫）的資料結構形成一一對應的對映關係，如果持久層是關係型資料庫，那麼，資料表中的每個字段（或若干個）就對應po的乙個（或若干個）屬性。
在日常的專案開發中，vo對應於頁面上需要顯示的資料（表單），do對應於資料庫中儲存的資料（資料表），dto對應於除二者之外需要進行介面形式傳遞的資料。
流程如下：
既然dto是展示層與服務層之間傳遞資料的物件，為什麼還需要乙個vo呢？
對於絕大部分的應用場景來說，dto和vo的屬性值基本是一致的，而且他們通常都是pojo，因此沒必要多此一舉，但不要忘記這是實現層面的思維，對於設計層面來說，概念上還是應該存在vo和dto，因為兩者有著本質的區別：
dto代表服務層需要接收的資料和返回的資料，而vo代表展示層需要顯示的資料
vo與dto的應用：
在以下才場景中，我們可以考慮把vo與dto二合為一：
當需求非常清晰穩定，而且客戶端很明確只有乙個的時候，沒有必要把vo和dto區分開來，這時候vo可以退隱，用乙個dto即可
dto是展示層和服務層之間的資料傳輸物件，而do是對現實世界各種業務角色的抽象，這就引出了兩者在資料上的區別，例如userinfo和user。
安全性問題：
對於乙個getuser（dto）方法來說，本質上它永遠不應該返回使用者的密碼，因此userinfo（do）至少比user少乙個password的資料
通過反射即可轉換
dto與do的應用：
（1）do具有一些不應該讓展示層知道的資料；
（2）do具有業務方法，如果直接把do傳遞給展示層，展示層的**就可以繞過服務層直接呼叫它不應該訪問的操作，對於基於aop攔截服務層來進行訪問控制的機制來說，這問題尤為突出，而在展示層呼叫do的業務方法也會因為事務的問題，讓事務難以控制。
do和po在絕大部分情況下是一一對應的，但是po是只含有get/set方法的pojo
public class beanutils
// 判斷doclass 是否為空
if (doclass == null)
try catch (exception e)
} /**
* do 轉換為dto 工具類
* * @param dtoentity
* @param doentity
* @return
*/public static dto dotodto(object doentity, classdtoclass)
// 判斷doclass 是否為空
if (dtoclass == null)
try catch (exception e)
}}
微服務安全測試的關鍵 介面安全機制
主要包括以下幾個方面 認證 確保你的使用者或客戶端真的是他們自己。授權 確保每個針對api的訪問都是經過授權的。審計 確保所有的操作都被記錄，以便追溯和監控。流控 防止使用者請求淹沒api。加密 確保出入api的資料都是私密的。下圖會對我們理解介面的 安全機制有很大的幫助，最右面是我們提供的api，...
微服務devops 用於微服務的安全DevOps
微服務devops 容器和微服務徹底改變了應用程式開發和基礎架構管理。他們還提出了新的安全挑戰，而沒有解決舊的挑戰。有哪些新的安全挑戰，您可以如何應對？微服務正在改變一切。不變的基礎架構，無共享架構和容器化應用程式 微服務 是當今大多數企業路線圖的重點。微服務提供了一種以小型，自治且可自我維持的能力...
如何保障微服務安全
原文 securing microservices摘要 如何保護微服務，確保微服務的安全，作者從保護應用程式安全和保護容器的安全兩個方面進行了闡述，以下是譯文 實現乙個微服務很難。部署乙個微服務應用程式複雜性也很高。保護微服務的安全就更難更複雜。從 開始呢？腦海中首先出現的一些詞是身份驗證和授權 防...