資安

筆者是飛天最早的研發人員之一，曾經參與從0到5000臺飛天集群和操作系統的構建。飛天是一個龐大的軟件系統，既有非常多的模塊，也要跑在幾萬臺物理機上，如何讓分佈式軟件高效地運行離不開監控、性能分析等環節，因此在飛天研發的第一天我們就同時開始研發飛天監控系統“神農”。神農通過採集大量的系統數據，幫助我們更好地理解系統、軟件協作複雜性背後的關係。同時神農也在伴隨著越來越大、越來越多海內外集群的飛天操作系統成長，支撐阿里巴巴集團和阿里雲的業務。在2015年，經歷過一番思考，我們決定把神農抽象成一個更底層的服務——SLS（日誌服務，第一天主要focus在日誌場景中），希望通過SLS能夠服務支撐更多的Ops場景，包括AIOps（智能分析引擎）。 一、構建可觀察性中臺的背景 先說說從一個工程師的角度看到的變化：對一個工程師而言，5年前的工作是非常細分的，研發的工作就是把代碼開發好。但隨著互聯網的發展，業務系統Scope越來越大，需要在質量、可用性和可運維性上有更高的要求。並且為了保障我們的業務是持續改進的，必須在工作中涉及到更多運營的因素，例如統計系統訪問、留存和體驗等情況。 從個人視角轉化到行業視角也能發現一個趨勢：在十幾年前，研發的時間會花在三個部分：創新（編碼），部署+上線，觀察+分析，並且部署+上線會花費大量的時間。近幾年雲計算和雲原生的興起解放了開發運維在部署、上線和環境標準化上的精力。但業務的高要求需要在各個環節中承擔更大的Scope，從多個視角來看待問題。背後就會有大量、碎片化的數據分析工作。 工程師生涯5年變化 如果我們把具體的數據分析工作進行拆分，可以拆解成一個簡單的黑盒。黑盒的左邊是數據源，右邊是我們對數據源觀測判斷後的行動。例如： · 在安全場景中，安全運營工程師會採集防火牆、主機、系統等日誌、根據經驗對日誌進行建模，識別其中的高危操作，生成關鍵性事件，系統根據多個事件進行告警。 · 在監控和運營場景中，這個過程是類似的。無非是把數據源和建模的方法做了替換。 所以我們可以看到，雖然各個場景角色不同，數據源不同，但在機制上我們是可以建立一套系統性分析框架來承載這類可觀察性的需求的。 二、中臺的技術挑戰 構建中臺的思路看起來很直接，要做這件事情有哪些挑戰呢？ 我們可以從數據源、分析和判別這三個過程來分析： · 第一大挑戰來自於數據源接入。以監控場景為例，業界有不同的可視化、採集、分析工具針對不同的數據源。為了能建立監控可觀察性體系，需要引入大量的垂直系統。這些系統之間有不同的存儲格式，接口不統一，有不同的軟件體驗，往往難以形成合力。 · 第二大挑戰來自於性能與速度。數據分析的過程實際上是把專家經驗（Domain Knowledge）沉澱的過程，而Ops場景一般都是Mission Critical過程，因此需要非常快地分析速度和所見即所得能力。 […]

“我們在一個月內見證了十年的變化”。因為新冠疫情期間加速使用遠程醫療，我們常常可以聽到這句話。據統計，在新冠病毒出現以前，英國國家衛生局每年處理約3.5億次診症，其中視頻診症僅佔1%。而目前，Docly、eConsult和AccuRx等公司正在改變這種狀況。AccuRx稱，英格蘭90％的初級保健診所現在用的是AccuRx的視頻通話系統。 遠程醫療最受業界關注的形式是遠程手術。雖然遠程手術不是什麼新鮮事物，但它正在迎來快速增長階段，甚至可以帶來巨大的利益。從作用上來看，遠程手術可以幫助克服世界上許多地方的醫生短缺問題，還可以改善培訓、提高行業水準及推動醫療行業的創新。 Proximie：遠程手術推動者之一 比如，Proximie公司就是遠程手術的領先推動者之一。Proximie是一家四年前成立的倫敦公司。外科醫生利用Proximie提供的網站平臺可以通過音頻、視頻和增強現實進行遠程協作。其創始人是整形外科醫生Nadine Hachach-Haram。在TEDWomen 2017上的一次演講中，她演示了基於Proximie平臺的真實操作。 ▲Proximie創始人兼首席執行官Nadine Hachach-Haram （圖：Ryan Lash） Hachach-Haram小時候沉迷於玩電子遊戲，她的父親是一位計算機工程師，Proximie公司的創立起初只是業餘愛好，或多或少有點偶然。 2015年，加利福尼亞的一名外科醫生測試了Proximie平臺的早期版本，他在全球微笑基金會（Global Smile Foundation）開展的一項計劃裡用Proximie平臺為祕魯的同事提供培訓，該計劃主要是為兒童提供顎裂修復手術。2016年，Proximie平臺首次在實時手術中使用，當時是為在加沙炸彈爆炸受害者做手術。2019年，英國國防部與Proximie簽了個多年期的合同，英國前線戰地醫院和處於世界各地的皇家海軍艦船可以使用Proximie系統的增強現實。 而如今，Hachach-Haram已經成為醫學領域的佼佼者，同時，她也是英國皇家外科醫學院（RCS）發表的2019年《外科手術的未來》報告的作者之一。 人工智能技術加快遠程手術升級 事實上，外科手術中的虛擬協作並不新鮮。例如，2000年首次獲批准使用的達芬奇系統（Da Vinci System），該系統可以支持精確的微創手術（稱為腹腔鏡或鎖孔手術），並且手術可以由離病人數千英里的外科醫生進行。當然，當時也有人對這個系統頗有微詞：每臺機器開價200萬美元，但只有相對很少的外科醫生受過使用該系統的培訓，患者的治療效果也沒有很大變化。 相對來說，Proximie是個高度優化的實時視頻平臺。Proximie要求非常低的延遲，這裡的延遲指圖像捕獲與圖像顯示之間的延遲。現在的延遲已降到200毫秒，這個速度大約是人類視覺皮層記錄運動的時間範圍極限。由於人工智能具有先進的增強現實功能和尖端的計算機視覺功能。這些技術的引入可以幫助外科醫生彙集與手術相關的數據和圖像，看到當下發生的情況，而且清晰度極高。

作為開發者，我們不過度區分服務端 server 客戶端 client，我們是 web developer，從事 web 開發，多去理解技術和實踐落地。 成為全棧工程師的道路 成為全棧工程師說不上難也說不上容易，其中技術積累佔了很大一部分： 緊跟前沿 掌握足夠多的輸入。 關注海外社區新消息發佈，業界的新產品新技術，學會高質量的獲取信息，堅持做和習慣做。 注重學習 & 不斷實踐 有屬於自己的思考和嚴謹的產出。 掌握高效學習方法，比如我們最近在做 k8s 容器集群相關的事情，需要理解底層設計和做集群調度，需要學習

在疫情期間，人工智能又順勢火了一把。由人工智能合成的新聞播報，每天都在向我們實時傳遞疫情信息。雖然每次只有短短的幾分鐘，但它出現著實讓我震撼了一把。 以往，都認為的人工智能距離我們的生活，還有一段很長的路要走。即便是智能算法、智能語音、自動駕駛，無人機/無人車送貨、自動生產線等智能化設備和系統早已經進入到實際生活當中。但是一直以來，我們都普遍地認為人工智能離我們還有很遠，我們還是安全的處在堤岸上的避風港，海風吹起的大浪還需要一段很長的時間才能拍打到腳踝上。然而這些簡短的新聞播報視頻卻實打實地告訴我們一個清楚的事實，人工智能這個大浪已經上岸了，很有可能在下一個瞬間就會拍到你的身上，狠狠的將你擊倒在地，然後就是海水淹過，可能連起身的機會都沒有。如果在現在這個人工智能兵臨城下的時刻，還沒有做出適時恰當的改變的化，可能真的會面臨失業。但我們能具體做些什麼樣的改變呢? 首先，我們要知道，到底是什麼讓我們失業? 人工智能爭奪人類工作的根本原因，就是它們能夠提供安全穩定快捷高效的產品和服務，節省時間和經濟上的成本，增加效益。就拿自動化生產線來說，全自動的生產線，不需要工人蔘與到生產中來，降低了管理成本，最大化的減少可能的人員安全問題，同時由於自動化生產的準確性、高效性以及工作時間長等特性，對比手工生產，它就能生產出巨大的效益，使得自動化生產成為必然選擇而非人工生產。自動化生產線早已經不是說說而已，著名的富士康就建設了全自動生產的代工工廠，不但減少的投入，同時還獲得了精良的產品，何樂而不為?也許以後那些大廠就不再需要人工進行生產了。 再就是無人機和無人車的送貨服務，在2013年，電商巨頭亞馬遜就已經開始測試無人機送貨，在今年，美國聯邦航空管理局已經批准亞馬遜無人機的配送項目，該項目宣稱無論你在何地，30分鐘都能將貨物準確遞送到手裡。在國內，順豐等快遞公司也早已在部署無人機配送項目，而無人車的送貨已經出現真實的場景中，只不過目前使用範圍還比較小。還有自動駕駛也已經登陸了，滴滴公司正在公路上測試無人駕駛的“滴滴車“，比亞迪顯然都要比他們快一步，已經在深圳推出了無人駕駛的公交車，無人駕駛正在逐步擴大入侵的腳步。AI產業大軍已經近在咫尺了，失業潮可能即將來臨。 我們能做什麼呢? 我們可以看到，人工智能能夠代替的，都是一些可以重複進行的工作，對於自主創造性要求較低的工作，如果能緊抓人工智能的這一缺點，就有很大可能保住飯碗，爭奪一片新天地。這裡有三點建議，可能會有所幫助。 第一， 量不如質，以精取勝 在人工智能的時代，人工的產量必定遠遠追趕不上人工智能的輸出，但，在質的方面還是可以與之競爭的，精品取勝的道路和方向應是永遠暢通正確的。質和量是商品服務的兩個方面，都能可以帶來豐厚的利潤，但是在人工智能的時代，量的優勢牢牢掌握在人工智能手中，我們幾乎不能攻破這座牢固的堅城。而質，則是我們必須要突破的地方，打造高質的精品，是人工智能所追趕不及的。就如同目前一些打造二次元道具的工作室製造，它們推出需要的精品，吸引眾多的動漫愛好者的關注，在這個時代迎來了屬於他們新的高峰。 第二， 內容為王，以獨特的內容制敵 網絡化的時代，信息高速傳播，同質化的事物越來越多，致使人們所追求的越來越是一些新穎奇特的與眾不同的事物。就如同幾十年前的追星一樣，明星只有那麼多，沒得選，但是現在不同，大把的明星排著隊等你追，你可以盡情的挑選。隨著大眾化的口味逐漸在向小眾化轉變，機會也就出現了，抓住小眾化的口味，生產提供對口內容化的產品服務，就能迎來勝利的轉機。前些年，互聯網產業的口號的流量為王，只要能夠抓住足夠的流量，就能獲得足夠的利潤，但是現在則完全不同，流量可能不是大問題，最主要的是內容。內容為王的時代從來沒有成為過去式，只要能夠生產出足夠新穎獨特的內容，無論在哪個時代都能勝出。內容是我們戰勝人工智能的核彈。創作文字和視頻同樣如此，做搬運工就能成為人生贏家的時代早已一去不復返，內容才是獲得勝利的關鍵所在。 第三， 順勢而變，融入到人工智能的大浪潮中 人工智能能夠將我們從原來的職位上驅逐，有一個根本的原因就是知識儲備不足，增加我們的知識量，融入到人工智能的大潮中，是解決這個問題的終極策略。同時，人工智能的到來，還會創造許多新職位，並且激發新的產業連，如自動化系統監控和維修、無人機的駕駛操控等，不過這都要求我們掌握一門與人工智能相關知識技術，學習和轉變成為了重點。即便這些都不行，還可以從根本出發，直接學習編程，直接參與到人工智能的製造當中，這絕對是比較好的解決途徑，沒有之一。編程看起來是件困難的事情，事實上它不僅是困難，而且還是一件很辛苦的事情，但那有很容易的事情呢，古語云“世上無難事，只怕有心人“，只要我們能夠堅持下去，找到恰當的學習方法，編程不會是阻攔你前進的障礙。 結語 人工智能是時代的發展的必然，人工智能的已經兵臨城下，無論如何都躲不過去，不如就融入到這股大浪潮中，與人工智能的大風浪搏擊。逆勢而為只會車毀人亡，到不如順勢而下，迎接另一個巔峰的到來。原文鏈接：https://ai.51cto.com/art/202010/628635.htm本文轉載自51CTO，本文一切觀點和機器智能技術圈子無關。在線免費體驗百種AI能力：【點此跳轉】

引言 上一章我們為發電子郵件準備了貼心的表單，完善的數據驗證，那麼本篇我們講解如何在laravel內發送一封電子郵件。 電子郵件非常方便，大家切勿濫用。 代碼時間 laravel集成了熱門且功能強大的SwiftMailer庫，為我們封裝了發送郵件所需要的底層邏輯，所以我們只需關注發送的邏輯，如何準備電子郵件的內容即可。 laravel配置文件 config/mail.php 內默認的 smtp 參數： ‘smtp’ => [ ‘transport’ => ‘smtp’, ‘host’ => env(‘MAIL_HOST’, ‘smtp.mailgun.org’),

1. 前言 現如今接口測試在軟件質量行業中的地位，已經越來越重要，相對於上層的UI自動化測試和下層的單元測試，接口測試的“低”投入、“高”回報，也成了絕大多數質量保障實踐的首選。 在開展接口測試時，往往很多時候都只在關注接口的功能性質量，而對於非功能性的質量保障驗證，比如性能、安全，在實際工程應用或者設計用例時關注度明顯不足（甚至很多壓根沒有這方面的測試實踐）。 今天就以Python系下requests庫（常用於接口測試）和Robot FrameWork框架為例，和大家聊聊在接口測試過程中，和功能需求同等重要的性能測試檢查項。 2. 接口測試需要考慮的性能檢查項 在接口測試過程中，除了要考慮產品需求的正常、異常、數據正確性等顯性功能需求質量外，還有很多隱性需求質量需要關注，以性能測試為例，常見需要關注的檢查項包括，但不限於： 1、單用戶登錄的響應時間是否小於 3 秒； 2、單用戶登錄時，後臺請求數量是否過多； 3、高併發場景下用戶登錄的響應時間是否小於 5 秒； 4、高併發場景下服務端的監控指標是否符合預期； 5、高集合點併發場景下，是否存在資源死鎖和不合理的資源等待； 6、長時間大量用戶連續登錄和登出，服務器端是否存在內存洩漏。 本文重點以接口響應時間為例，介紹如何在requests庫和Robot

Redis 客戶端緩存 緩存的解決方案一般有兩種： 【L1】 內存緩存（如 Caffeine、Ehcache） —— 速度快，進程內可用，但重啟緩存丟失，出現緩存雪崩的問題。 【L2】集中式緩存（如 Redis）—— 可同時為多節點提供服務，但高併發下，帶寬成為瓶頸。 業內有很多開源框架來解決以上問題，既能有 L1 速度，並且擁有 L2 集群態。如下 J2Cache 兩級緩存框架 hotkey 熱點數據實時同步

簡介 在企業級開發中、我們經常會有編寫數據庫表結構文檔的時間付出，從業以來，待過幾家企業，關於數據庫表結構文檔狀態：要麼沒有、要麼有、但都是手寫、後期運維開發，需要手動進行維護到文檔中，很是繁瑣、如果忘記一次維護、就會給以後工作造成很多困擾、無形中製造了很多坑留給自己和後人，於是需要一個插件工具 screw來維護。 screw 特點 簡潔、輕量、設計良好。不需要 powerdesigner 這種重量的建模工具 多數據庫支持 。支持市面常見的數據庫類型 MySQL、Oracle、SqlServer 多種格式文檔。支持 MD、HTML、WORD 格式 靈活擴展。支持用戶自定義模板和展示樣式 支持數據庫類型 [✔️] MySQL [✔️] MariaDB

關於延遲加載 在 Spring 中，默認情況下所有定的 bean 及其依賴項目都是在應用啟動時創建容器上下文是被初始化的。測試代碼如下： @Slf4j @Configuration public class DemoConfig { public DemoConfig() { log.warn(” > > > demoConfig

 作者 | 亦盞 前言 隨著微服務的流行，越來越多公司使用了微服務框架，微服務以其高內聚、低耦合等特性，提供了更好的容錯性，也更適應業務的快速迭代，為開發人員帶來了很多的便利性。但是隨著業務的發展，微服務拆分越來越複雜，微服務的治理也成了一個比較令人頭疼的問題，我相信下面這些場景大家或多或少都遇到過。 場景一：發佈是天大的事情，每一次的發佈，都會出現執行到一半的請求中斷掉，上游繼續調用已經下線的節點導致報錯的現象。發佈時收到各種報錯，同時還影響用戶的體驗，發佈後又需要修復執行到一半的髒數據。 上述場景還是在新版本沒有任何問題的情況下，如果新版本有問題，則會導致大量業務直接請求到有問題的新版本，輕則修復數據，重則嚴重影響用戶體驗，甚至產生資損。最後不得不每次發版都安排在凌晨兩三點發布，心驚膽顫，睡眠不足，苦不可言。 場景二：大半夜某個服務節點出現異常，上游仍舊不斷地調用，出現很多異常和各種報警短信。被報警吵醒後，想直接在線上修復，有點難，想保留現場又害怕拖垮整個應用，只好先重啟為上。 但是這只是治標不治本的方式，因為很難復現從而無法有效定位，可能明天又被吵醒，繼續重啟。上述場景還是建立在報警系統比較完善的情況下，如果沒有完善的報警系統，嚴重情況可能整個業務系統都被單機異常拖垮。 場景三：公司業務壯大了，部門組織變複雜後，微服務模塊越來越多。我不清楚發佈的服務到底被誰調用了，所以我不知道能否安全地下線一個服務。我這個應用的這個接口是個敏感接口，我只希望得到我授權的應用才能調用，而不是直接從服務註冊中心得到我的地址就能直接調用，但是目前好像還做不到。 以上三個場景確實是使用微服務之後帶來的痛點，這時候有個人告訴你，這些問題，我都知道怎麼搞定，我有著豐富的經驗，知道怎麼解決，你肯定很開心。 然後高薪請進來了，確實不錯，各種架構圖、框架原理，框架修改點都非常清晰而且功能確實完美。最後評估對當前系統的修改成本，需要搭建三套中間件服務端，增加 4 箇中間件依賴，修改幾萬行代碼和配置。 “打擾了，還是業務重要，產品經理給的需求還沒完成呢，剛剛說的場景也沒那麼痛苦，不就幾個小問題嘛，真的沒事。” 這時候 EDAS 告訴你，EDAS 的微服務解決方案，不需要做任何的代碼和配置的修改，就能完美地解決上面說的三個場景中的問題。 你，不心動嗎？ 是的，你沒看錯，只要你的應用是基於 Spring