K60至尊版狂暴引擎2.0加持：超177萬跑分斬獲性能第一
Redmi的后性能時代戰略發布會今天下午如期舉辦，在本次發布會上，Redmi公布了多項關于和聯發科的深度合作，以及新機K60 Ultra在軟件和硬件方面的特性，例如：“K60 至尊版，雙芯旗艦
近年來，國家采取了多項重要舉措來加強個人數據保護，包括實施《中華人民共和國網絡安全法》和《個人信息保護法》等法律法規。這些舉措旨在確保用戶隱私的安全，同時確保企業合規運營。在處理敏感數據時，企業有責任采取適當的措施來保護用戶信息。
在數據保護方面，日志記錄成為一個需要特別關注的敏感信息領域。因此，本文將重點介紹轉轉在日志脫敏方面的應用與實踐。
目標：對日志內的手機號、身份證號、銀行卡號等敏感信息脫敏，建立一個可持續的日志敏感信息管控機制。
措施：
圖片
我們的第一步是利用大數據離線掃描服務日志，并使用正則表達式匹配敏感信息。
然而，第二和第三步是挑戰的關鍵，即如何在不干擾業務正常迭代排期的情況下，推動大量服務的日志做脫敏。我們希望使用技術手段盡量降低業務日志脫敏的人力成本。
參考《轉轉日志規范》查看標準日志輸出要求，在此基礎之上，提供一些工具輔助業務對日志脫敏。
【推薦】JavaBean類需實現toString()方法，日志直接打印對象，慎用JSON工具將對象轉換成String。
我們開發了脫敏工具類，期望業務同學在實現JavaBean toString()方法的同時，使用脫敏工具對敏感字段使用脫敏。
圖片
public final class DesensitizeUtil { /** * 根據字符串長度匹配不同的脫敏函數, 強制脫敏 */ public static String desensitizeByInputLength(String input) { int length = input.length(); // 手機號 if (length == 11) { return desensitizePhoneNumber(input); } // ,,, } /** * 脫敏手機號, 前3位和后4位，中間的數字用*代替 */ public static String desensitizePhoneNumber(String phoneNumber) { // 11位手機號 if (phoneNumber.length() == 11) { return phoneNumber.substring(0, phoneNumber.length() - 8) + "****" + phoneNumber.substring(phoneNumber.length() - 4); } return phoneNumber; } // 省略其他脫敏函數...}在某些日志記錄的場景中，會打印包含敏感字段的JSON格式的數據，需要對其中的敏感信息進行脫敏處理。
在常見的JSON工具中，比如Jackson，可以使用自定義的序列化器/反序列化器來實現脫敏。下面以Jackson為例進行說明：
首先，我們可以定義一個注解來標注哪些字段需要脫敏處理：
/** * 脫敏注解 */@Target({ElementType.FIELD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface Desensitize { }然后，我們可以創建一個自定義的Jackson模塊，通過繼承BeanSerializerModifier類來修改字段的序列化行為。在這個類中，我們可以根據字段上的Desensitize注解來判斷是否需要進行脫敏處理：
/** * Jackson脫敏序列化修改器 */public class JacksonDesensitizeSerializerModifier extends BeanSerializerModifier { @Override public List<BeanPropertyWriter> changeProperties(SerializationConfig config, BeanDescription beanDesc, List<BeanPropertyWriter> beanProperties) { for (BeanPropertyWriter beanProperty : beanProperties) { // 只針對使用了@Desensitize的字段做脫敏 Desensitize desensitize = beanProperty.getAnnotation(Desensitize.class); if(desensitize != null) { // 指定自定義的序列化器 beanProperty.assignSerializer(new Desensitization()); } } return beanProperties; } /** * Jackson序列化器 */ public class Desensitization extends StdSerializer<Object> { @Override public final void serialize(Object value, JsonGenerator gen, SerializerProvider provider) throws IOException { // 根據長度對字段做脫敏 String desensitize = DesensitizeUtil.desensitizeByInputLength(String.valueOf(value)); gen.writeString(desensitize); } }}最后，我們需要注冊這個自定義的模塊到Jackson中
/** * JSON工具 */public class JsonUtil { private static final ObjectMapper DESENSITIZE_OBJECT_MAPPER = newObjectMapper(); private static ObjectMapper newObjectMapper() { ObjectMapper mapper = new ObjectMapper(); //增加脫敏序列化器 SimpleModule simpleModule = new SimpleModule("SimpleModuleDesensitize"); simpleModule.setSerializerModifier(new JacksonDesensitizeSerializerModifier()); mapper.registerModule(simpleModule); return mapper; } /** * 對象轉JSON的自動脫敏工具 */ public static <T> String object2DesensitizeString(T object) throws JsonProcessingException { return DESENSITIZE_OBJECT_MAPPER.writeValueAsString(object); } //...}對于業務同學而言，只需在需要脫敏的對象上添加脫敏注解，然后使用我們提供的JsonUtil進行脫敏操作，實現簡單高效。
/** * 需要脫敏的對象 */public class User { /** * 標記此字段需要脫敏 */ @Desensitize private String mobile; private String username; //getter setter...}User user = new User();user.setAge(18);user.username = "zhangsan";user.password = "123456";JsonUtil.object2DesensitizeString(user);//輸出結果: {"mobile":"135****5555","username":"張三"}注意：以上代碼只是一個示例，并不完整。在實際使用中，還需要根據具體的需求來靈活實現脫敏處理。
在實際實施過程中，以上兩個方案遇到了很多阻礙。主要問題在于業務同學手動維護Bean的toString()方法過于繁瑣、重復工作多、容易遺漏對象并導致增加或刪除字段時需要不斷修改toString()函數。此外，業務服務所依賴的Bean來源復雜，有可能是其他業務提供的第二方Jar包或第三方Jar包。
因此，在實際應用中，業務同學更傾向于將Bean序列化為JSON并輸出到日志中，如下所示：
log.info("data={}", JsonUtil.object2DesensitizeString(bean));然而，這種方法不符合《轉轉日志規范》要求，而且忽略了JSON序列化性能的問題。此外，這種方案也需要耗費大量的人力資源：需要評估每一行日志，以確定是否需要添加JSON脫敏功能。
因此，業務同學提出了以下需求：是否可以實現類似Lombok一樣的功能，只需在Bean的字段上添加脫敏注解，就能在編譯期自動實現脫敏后的toString()函數？這樣的話，在打印日志時直接打印對象即可自動脫敏。
經過調研發現，Lombok在編譯時利用APT（Annotation Processing Tools）生成代碼，實現了自動化的代碼生成過程，從而簡化了開發工作。
APT（Annotation Processing Tool）是Java的編譯期注解處理器。它允許開發人員在編譯期間處理注解，并根據注解和相關對象的信息生成Java代碼模板或配置文件等。
APT的使用可以提高程序性能，因為它在代碼編譯時完成注解處理，而不是在運行時使用反射方式處理注解。
著名的開源框架，如Lombok、MapStruct和AutoService等，也使用了類似的技術來優化代碼的生成和處理過程。
圖片
我們利用APT技術實現了這樣的功能：如果一個類沒有重寫Object.toString()方法，在編譯時會自動為該類生成一個脫敏后的toString()方法。這個自動生成的toString()方法能夠識別脫敏注解，并在生成的toString()方法內對敏感信息進行脫敏處理。
在Java編譯后的Class文件中，toString()方法可能來自三個來源：源代碼、轉轉APT處理、Lombok等。優先級為：源代碼 > 轉轉APT處理 > Lombok等其他APT。簡言之，我們的APT處理不會覆蓋源代碼中定義的toString()方法，但會覆蓋由Lombok生成的toString()方法。
比如，我們有以下源碼：
class User { private String username; /** * 密碼，增加了脫敏注解 */ @Desensitize private String password;}在接入轉轉APT后，反編譯的Class文件如下：
class User { private String username; @Desensitize private String password; public String toString() { StringJoiner sj = new StringJoiner(", ", "User[", "]"); if (this.username != null) { sj.add("username=" + this.username); } if (this.password != null) { sj.add("password=" + DesensitizeUtil.desensitizeByInputLength(value)); } return sj.toString(); }}測試如下：
User user = new User();user.username = "zhangsan";user.password = "123456";System.out.println(user); //輸出結果: User[username=張三, password=1****6]這個功能的上線大大降低了業務同學實現日志脫敏的工作量，只需為字段添加脫敏注解即可。同時，也解決了線上對象未重寫Object.toString()時打印日志的尷尬問題。
不過，在落地APT過程中，我們也遇到了一些問題，希望能給讀者提供一些有收益的參考。
在某個服務的Spring Bean上，有一個包含大量本地緩存的List字段，這個服務會打印Spring Bean對象到日志中。在引入轉轉APT之前，一切正常；但引入后，出現了頻繁的OOM問題。通過內存分析后發現，問題出在轉轉APT為Spring Bean自動生成的toString()函數內產生了大量的字符串上。
@Servicepublic class AppService { /** * 本地緩存 */ private List<Object> cache = new ArrayList<>(); }@Autowiredprivate AppService service;log.info("service={}", service);我們觀察到大部分帶有本地緩存（或者高內存占用字段）的對象都是Spring的Bean，因此，我們對轉轉APT進行了修改：即不再為Spring Bean生成toString()函數。
某個服務的JavaBean使用了原生JDK的序列化/反序列化工具，但是這個JavaBean卻沒有添加serialVersionUID。
class Person implements Serializable { // 沒有定義serialVersionUID // private static final long serialVersionUID = -55721300387280236L;}Java序列化機制使用long型的serialVersionUID字段來標志類的版本號；序列化對象時，JVM會將serialVersionUID的值寫入序列化數據中；反序列化時，JVM會將序列化數據中的serialVersionUID與對應類中的serialVersionUID進行比較，若不同，則拋出InvalidCastException；若版本號相同，則能夠進行反序列化。
當一個類沒有顯式定義serialVersionUID時，JVM會自動根據類的信息計算生成一個默認的serialVersionUID。這樣，在類發生變化時，自動生成的serialVersionUID可能會改變，導致無法正確反序列化之前的數據。
引入轉轉APT后，由于自動生成了toString函數，類信息發生變化，導致serialVersionUID也發生了改變，進而導致反序列化失敗。
解決方式是將之前默認生成的serialVersionUID找到，并將其添加到類的源碼中。
還有一種快速落地的方法是，通過在應用程序內部統一攔截日志輸出，正則匹配敏感信息，并利用脫敏工具進行脫敏處理。
我們沒有使用這種方式的原因是因為：脫敏應盡量避免正則匹配，容易誤傷且性能低下。
上文提過，服務內依賴的Java Bean來源十分復雜，我們目前只解決了對象本身的脫敏問題。而對于服務依賴的Jar包版本控制，仍需要業務團隊梳理依賴關系，并手動修改脫敏后的Jar包版本，這一過程仍需要耗費較多的時間和人力。
考慮到這個問題，是否可以為每個服務提供一個依賴關系管控系統？該系統可以對Jar包的版本實現自動更新、自動化測試、灰度發布、自動發布和回滾等一系列功能。對于轉轉目前的情況來說，我相信這不是一個技術問題，而是一個需要更多時間來完善的TODO List。
圖片
一個小小的功能日志脫敏，卻經歷了多個階段與挑戰，從敏感日志的發現到開發脫敏工具類，再到Json脫敏，再到APT脫敏，最終推動業務應用。核心的挑戰在于如何做好推動相關的工作？
我認為，推動相關工作的核心在于有效應對內在和外在的因素。然而，外部因素對推動的阻力常常更大，要成功推動工作，轉變外部阻力為內部動力至關重要。而對于推動者而言，換位思考、勇于挑戰未知、深入追根究底的打磨產品會使產品更容易被接受和推廣。
本文鏈接：http://m.www897cc.com/showinfo-26-61003-0.html針對大規模服務日志敏感信息的長效治理實踐
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： vivo 海量微服務架構最新實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號