資安

Uniswap.php 開發包適用於為PHP應用快速增加對Uniswap協議的支持能力。即支持使用自有部署以太坊區塊鏈節點的應用場景，也支持使用第三方節點的輕量級部署場景。官方下載地址：Uniswap.php對接開發包。 1、開發包概述 Uniswap.php開發包主要包含以下特性： 一鍵部署Uniswap協議，便於快速開發與測試 支持Uniswap協議的全部接口，並提供開發人員友好的API 支持ERC20/ERC20、ETH/ERC20等各種交易對的流動性添加、移除與兌換交易 支持自動做市價格計算與滑點計算 支持以太坊交易gas用量與gas價格的自動估算與手動設定 支持EIP712簽名授權，單一交易內完成流動性維護 Uniswap.php開發包運行在 Php 7.1+ 環境下，當前版本1.0.0，主要類/接口及關係如下圖所示： Uniswap.php開發包的主要代碼文件清單參見官網說明：http://sc.hubwiz.com/codebag/uniswap-php/ 2、使用示例代碼 2.1 編譯合約 在終端進入項目目錄，執行如下命令編譯Uniswap及開發包提供的測試Token合約： ~$ […]

演講嘉賓簡介：吳林(無才)，阿里雲智能數據庫PD，18年IT領域工作經驗，對數據庫、雲計算、金融領域有深度實踐，現負責阿里雲數據庫專屬集群MyBase產品。 以下內容根據演講視頻以及PPT整理而成。觀看回放https://developer.aliyun.com/live/245475更多課程請進入“數據庫大講堂”瞭解https://developer.aliyun.com/topic/database/lives本次分享主要圍繞以下四個方面：一、背景介紹二、共享和專屬三、雲時代需要什麼樣的數據庫服務四、問答環節 一、背景介紹 世界只需要5臺計算機——笑話還是預言在1943年的時候，IBM董事長托馬斯·沃森（老沃森）提出了一個預言：世界只需要5臺計算機.當時,世界上的很多人相信這個預言。而當今天回頭再看1943年老沃森提出的這個預言，很多人認為是一個笑話，因為現在計算機非常多。其實老沃森在做這個預言的時候肯定是有歷史背景的，因為在1943年的時候，全世界的數據量也非常小，而隨著計算機技術發展到今天，整個世界的數據量變大非常大，需要以萬億億來進行計算，因此不能僅靠5臺計算機進行計算。 我們所熟知的微型機在大家的生活中可能會接觸到臺式機和筆記本電腦，這類電腦屬於專屬計算機，一般情況下不會共享。 大型機除了上述微型機之外還有很多其他類型的計算機，比如下圖所示的大機計算機，其體積非常大，可能佔據整個房間，而且線非常多並且雜亂。此外，當時使用的主要是真空管和晶體管等，並且主要提供給科研人員使用，這是因為其輸入非常複雜，計算機輸入所使用的是大家可能沒有見過的卡帶，也就是在卡帶紙條上進行打孔作為輸入。此外，機房的環境非常惡劣，因為晶體管和真空管等散熱非常嚴重，因此需要有水來散熱。上圖中右側是近代金融機構和大型企業所使用的大型機，有點類似在阿里雲機房看到的機櫃，一個機櫃基本上是一個大型主機的規模。在老沃森所處的歷史背景下，一臺大型機處理一個企業的數據規模基本上是滿足要求的。 與大型機相對的就是小型機，以前有一個話題是“去IOE”，所謂“IOE”分別代表IBM、Oracle和EMC。下圖是2013年5月17日，阿里集團最後一臺IBM小型機下線的場景。雲時代為什麼小型機要下線，是因為我們要進入雲時代。機房中，機架上的每一排都是刀片服務器，而需要散熱，有很多風扇，因此在機房中非常吵。其實，回到老沃森提出的全世界只需要5臺計算機這個預言，其實他說的是全世界需要有5大中心節點來處理大家的需求。在雲時代，像亞馬遜、微軟、阿里雲以及谷歌等雲產商來全球用戶提供服務，從這一點來看，老沃森說的也沒有錯。進入雲時代以後，很顯然，大家都希望能夠共享，這是因為在公有云中，大家都希望能夠隨時隨地享受到雲服務。 二、共享和專屬 數據庫發展歷程今天分享的主題是共享和專屬，在以前的大型機時代，肯定是專屬於某一個大型企業和科研機構的。而在雲時代，則走向了共享經濟，大家可以隨時隨地享受到便捷的雲服務。數據庫的歷史發展非常久遠，最早的大型機是在19世紀50年代出現的。標準意義上的大型機是從1964年推出的第一款S360機器開始，當然之前可能還有一些沒有量產的機型在50年代就已經出現了。當時出現的數據庫有層次數據庫和網狀數據庫，層次性數據庫和樹狀結構非常相似，像是具有根節點的倒立的樹，其中具有代表性的層次數據庫就是IBM IMS。在小型機時代，出現了關係型數據庫，包括MySQL、Oracle、IBM DB2等。進入PC時代之後，數據呈現出百花齊放的狀態，能夠看到NoSQL數據庫、開源數據庫以及進入雲時代，阿里雲等廠商所提供的雲原生數據庫，能夠滿足更多客戶和場景的訴求。 傳統自建數據庫的挑戰進入雲時代之後，雲廠商會提供雲數據庫服務，但是依然會有很多用戶會選擇自建數據庫。而對於企業而言，所需要維護的數據庫數量非常多，雖然現在很多企業選擇使用開源數據庫，不需要為商業許可證付費，但是對於自建數據庫而言，運維成百上千個數據庫的壓力非常大。而如果企業選擇使用開源數據庫，技術來源於自身的積累或者開源社區，缺少商業服務，而商業數據庫的服務則是收費的，比如Oracle和SQL Server，收費是非常昂貴的。 三、雲時代需要什麼樣的數據庫服務 在雲計算時代，我們所需要的數據庫服務需要關注資源、成本、安全、運維、內核的完整方案。 資源隔離對於數據庫的資源隔離而言，主要有幾種類型，包括物理資源隔離、ECS資源隔離以及Docker資源隔離。本次分享中主要介紹物理資源隔離，大家在使用雲服務的時候需要選擇使用共享實例還是獨享實例。 物理機資源隔離阿里雲對於物理資源隔離分成了共享實例、專享實例、獨享實例以及獨佔主機實例。對於共享實例而言，一個物理部署裡面可以創建多個數據庫，讓數據庫1服務於A客戶，數據庫2服務於B客戶，可以通過賬號進行隔離。對於專享實例而言，就是說這一個數據庫實例就是給某一個用戶或者說企業使用的，不會和其他的用戶在一起，一般是通過Cgroup進行資源隔離。所謂獨享實例就是希望對於資源在一定範圍內能夠保證資源獨佔性。對於更加“土豪”的客戶而言，就可以使用獨佔主機實例。 使用Cgroup進行資源隔離在使用Cgroup進行資源隔離時，阿里雲數據庫使用了memory、vlkio、cpu三個子系統分別對實例的內存、IO和CPU時間片資源進行了隔離。使用cpu.share配置各個實例的權重，根據Instance_leve表的limit_memory值進行內存隔離，並根據iops進行配置隔離。針對獨享實例，CPU子系統不能完全避免CPU資源的競爭，開始引入CPUSET對獨享實例綁定CPU核心資源。獨享實例使用CPU+CPUSET兩個子系統隔離CPU資源。綁定的CPU核心為邏輯核心，不考慮被綁定的邏輯核心是否在相同的物理核中。 CPUSET由於獨享實例已經使用CPUSET綁定CPU核心，而不同實例綁定不同的CPU核心，因此不會相互爭搶CPU核心資源。阿里雲數據庫團隊在使用CPUSET時設置了獨享實例CPU核心規格均為偶數，如2、4、8、16、32，並同時考慮邏輯核和物理核之間的關係，讓一個物理核虛擬出兩個邏輯核，避免不同獨享實例之間共享相同的物理核心而產生資源爭搶。雲數據庫服務形態對於資源隔離的要求而言，在專享服務裡面，雲服務就是共用資源池，因此用戶不知道自己的機器是哪一個，那麼很有可能不同用戶的數據庫實例出現在同一臺物理機上，如果某一個客戶使用的資源比較多，那麼就有可能會產生資源爭搶。而對於一些對於性能、安全要求比較高的客戶而言，則希望在公共雲裡面對於某些資源進行獨佔。 雲數據庫專屬集群基於用戶的上述考量，阿里雲就推出了雲數據庫專屬集群MyBase，這個產品就是為了解決用戶的此類問題。阿里云云數據庫專屬集群產品已經上線一段時間了，現在已經能夠支持MySQL、PostgreSQL、SQL

引言 上一章我教會大家如何在3分鐘的時間，通過laravel躋身geek之列（聽一下就好[捂嘴.jpg]）。實現了一個簡單的命令行，和一個複雜的發送郵件通知的功能。可是細心的讀者你發現了沒有，使用自定義的命令行，全程我們沒有輸入一個參數，沒有一個數據，這，這，這，太不尋常了吧！ linux下的命令，沒有一個是不帶參數自己玩兒的！所以本文教你改造命令行，做一個標準的應用程序。 事前詢問 首先我們要區分獲取參數的兩種方式，一種是在輸入命令行時直接給定的，還有一種是在程序運行過程中，等待用戶輸入信息之後才能繼續。先說第一種方式，也分為兩種，一種叫參數 argument，一種叫選項 option。在laravel程序裡，這兩個名字沒有變化。 比如，有一個密碼重置的命令行工具，要求傳入一個 userId 用於標記用戶的身份，在類的聲明中指明使用方式： protected $signature = ‘password:reset {userId}’; 假設上述類已經完成功能開發，在命令行中調用： php artisan password:reset 5

1. 前言 集合是用來存儲多個數據的，除了基本類型之外，集合應該是java中最最常用的類型了。java中的集合類型一般都集中在java.util包和java.util.concurrent包中。 其中util包中的集合類是基礎的集合類，而concurrent包中的集合類是為併發特別準備的集合類。 集合類的父類有兩個，一個是java.util.Collection, 一個是java.util.Map。 先看下Collection的定義： public interface Collection<E> extends Iterable<E> { } Collection繼承自Iterable接口，表示所有的Collection都是可遍歷的。並且Collection中可以保存一種數據類型。 再看下Map的定義： public interface Map<K, V>

零售雲是阿里三朵業務雲：零售雲、金融雲和政務雲之一，將開闢阿里在電商、零售行業的新藍海，2B快速交付、賦能合作伙伴更快業務增長和節省成本。雲原生是零售雲的最重要的技術底座，雲原生是什麼，會走向哪裡，在零售2B交付的場景上該如何應用，怎麼能夠結合幫助建設零售雲系列產品體系，值得我們的思考和探索，也將有效指導我們接下來幾年的零售雲項目和產品建設。 雲原生定義、阿里巴巴雲原生架構方法論及產品體系 雲原生定義 Cloud Native 翻譯為雲原生，是 Matt Stine 提出的一個概念，它是一個思想的集合，包括 DevOps 、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。Cloud Native 既包含技術（微服務，敏捷基礎設施），也包含管理（DevOps，持續交付，康威定律，重組等）。Cloud Native 也可以說是一系列技術、企業管理方法的集合。 雲原生的本質 雲原生本質是以應用為中心，讓應用能最大限度享受到雲計算的紅利。雲原生是雲計算的下一站，雲原生架構是引領未來十年的新一代技術架構。雲原生讓雲計算變得標準、開放、簡單高效、觸手可及。

介紹 Spring Cloud Config為分佈式系統中的外部配置提供服務器和客戶端支持。使用Config Server，您可以在所有環境中管理應用程序的外部屬性。客戶端和服務器上的概念映射與Spring Environment和PropertySource抽象相同，因此它們與Spring應用程序非常契合，但可以與任何以任何語言運行的應用程序一起使用。隨著應用程序通過從開發人員到測試和生產的部署流程，您可以管理這些環境之間的配置，並確定應用程序具有遷移時需要運行的一切。服務器存儲後端的默認實現使用git，因此它輕鬆支持標籤版本的配置環境，以及可以訪問用於管理內容的各種工具。很容易添加替代實現，並使用Spring配置將其插入。 引入pom相關jar包，其中pom.xml配置如下： <project xmlns=”http://maven.apache.org/POM/4.0.0″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd”> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.ml.honghu</groupId> <artifactId>commonservice</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>commonservice-config</artifactId> <packaging>jar</packaging>

前言 2013年，當我第一次接觸穩定性的時候，我是有些懵的，當時完全不知道穩定性是什麼，也不清楚要做什麼。在接下來的8年裡，我先後在菜鳥、天貓、盒馬從事中間件、業務系統、架構等方面的工作，期間一直穿插著負責穩定性和大促的保障工作。我的心態，大致經歷過以下幾個階段： low：完全不懂，覺得穩定性就是做別人安排好的一些表格和梳理，不知道自己該做啥，穩定性好low； 煩：各種重複的會議，做好了是應該的，做不好就是責任，很煩很焦慮； 知道該做什麼，但是累：各種報警和風險，每天需要擔心，想要不管又過不了自己心裡那關；大促時候天天熬夜，各種壓測，最終自己累得夠嗆； 發現結合點：發現在採用系統化思維之後，穩定性與系統自身的結合變得緊密，穩定性成為一種基線，找到了穩定性中的關鍵點和重點。 主動驅動：發現線上業務和線下業務的穩定性差別，理解並主動調整在不同業務團隊採取的穩定性策略，探究在穩定性中的自動化、工具化，系統化建立穩定性機制； 形成體系：形成穩定性體系化思考，明確穩定性每一個點在業務團隊大圖中的位置，探究系統彈性建設；近兩年來，穩定性不再僅僅侷限於之前的大促保障和平時的穩定性輪值，越來越體系化，在保障體系、監控體系、資源體系、質量保障、變更管控等多個方面，越來越系統。阿里的各個事業部，也紛紛成立專職的SRE安全生產團隊。然而仍有很多人和業務團隊，對於穩定性的理解和認知未形成一個體系化的機制，下面就結合我在業務團隊系統穩定性上的認識，以及最近2年在盒馬的一些思考，做一個分享。 什麼是SRE SRE（Site Reliability Engineering，站點可靠性/穩定性工程師），與普通的開發工程師（Dev）不同，也與傳統的運維工程師（Ops）不同，SRE更接近是兩者的結合，也就是2008年末提出的一個概念：DevOps，這個概念最近也越來越流行起來。SRE模型是Google對Dev+Ops模型的一種實踐和拓展（可以參考《Google運維解密》一書），SRE這個概念我比較喜歡，因為這個詞不簡單是兩個概念的疊加，而是一種對系統穩定性、高可用、團隊持續迭代和持續建設的體系化解決方案；那麼要如何做好一個SRE呢，這是本文要探討的話題。 1，心態&態度 1.1，誰適合做穩定性？ 就像前言裡我做穩定性前期的心態一樣，穩定性最初上手，是提心吊膽、不得其門而入的，所以想要做好穩定性，心態最重要，業務團隊想要找到合適做穩定性的人，態度也很重要。對於業務團隊，要如何挑選和培養團隊中最合適做穩定性的人呢？ 必須選擇負責任的人，負責任是第一要素，主動承擔，對報警、工單、線上問題、風險主動響應，不怕吃苦；一個不負責任的人，遇到問題與我無關的人，邊界感太強的人，難以做好穩定性的工作； 原則上不要選擇新人，對於團隊leader而言，“用新人做別人不願意做的工作”，這個決定比較容易做出，但是這也相當於是把團隊的穩定性放在了一定程度的風險上，用新人做穩定性，其實只是用新人佔了穩定性的一個坑而已。新人不熟悉業務，不瞭解上下游，最多隻能憑藉一腔熱血，對業務和系統感知不足，容易導致線上風險無法被快速發現、故障應急無法迅速組織。 不要用過於”老實”的人，這裡的“老實”的定義是不去主動想優化的辦法，不主動出頭解決問題，但是很能吃苦，任勞任怨，也很能忍耐系統的腐爛和低效；這樣的人平時很踏實，用起來也順手，但是卻無法主動提高系統穩定性，有的時候反而會給系統穩定性造成傷害（穩定性就像大堤，不主動升級，就早晚會腐爛）。 1.2，業務團隊如何支持穩定性SRE人員 給資源，穩定性從來不只是穩定性負責人的事情，而是全團隊的事情，穩定性負責人要做的是建立機制，主動承擔，但是穩定性意識，要深入到團隊所有人腦子裡，穩定性的事情，要能夠調動團隊一切資源參與。

什麼是WebView WebView是術語，是指網頁視圖。能加載顯示網頁，可以將其視為一個瀏覽器。它使用了WebKit渲染引擎加載顯示網頁。 可以內嵌在移動端，實現前端的混合式開發，大多數混合式開發框架都是基於WebView模式進行二次開發的。比如：APIcloud、uni-app等等的框架。 uni-app裡的web-view web-view是一個web瀏覽器組件，可以用來承擔網頁的容器，會自動鋪滿整個屏幕 各小程序平臺，web-view 加載的 url 需要在後臺配置域名白名單，包括內部再次 iframe 內嵌的其他 url 。 詳細屬性查看：uni-app裡的web-view 通訊方法 引入SDK 嵌入的h5項目或者頁面不是uni-app項目搭建的話，需要在 index.html 頁面或者是當前的HTML頁面引入uni-app項目的API ,這樣才能使用,才能相互通訊。

忘記root密碼的時候，往往會進入單用戶模式重置root密碼。任何人能通過未設防grub重置root密碼是很危險的事，本文以centos8為例介紹設置GRUB賬戶給GRUB加密，避免能直接進入單用戶模式Centos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼 Cento8在我實際測試用這個方法在centos8是有效的。 在root權限編輯”grub.d”目錄下的”00_header”文件，命令模式輸入大寫G，跳轉到文件尾部。 vim /etc/grub.d/00_headerCentos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼 在尾部追加下面的語句，兩處admin位置代表賬戶，qwe123位置代表密碼，可以自行設置其他。 cat <set superusers=’admin’password admin qwe123E0FCentos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼文件編輯保存，更新一下grub文件 grub2-mkconfig -o /boot/grub2/grub.cfgCentos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼然後重啟，在開機grub選擇頁面按e進入編輯引導，如果有需要登錄且輸入對應的賬戶密碼進入編輯，即為設置成功。Centos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼 Centos7.2/Centos8首先設置密碼 grub2-set-password記住密碼，輸入兩次確認密碼:Centos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼密碼密文存放在：/boot/grub2/user.cfg文件中Centos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼這樣生成的默認賬戶是root，有需要可以把root修改成其他的: vim /etc/grub.d/01_usersCentos8加密GRUB防破解root密碼Centos8加密GRUB防破解root密碼 最後一步更新grub。 grub2-mkconfig

為了應對冠狀病毒在世界各地的傳播，許多組織部署了VPN解決方案，包括Fortigate VPN，以允許僱主在家工作。VPN解決方案的配置對於保證組織的安全和避免危險的意外非常重要。 根據網絡安全平臺提供商SAM Seamless Network統計，超過20萬個企業已經部署了具有默認設置的Fortigate VPN解決方案。這種選擇允許攻擊者提供有效的SSL證書，並對員工的連接執行中間人（MitM）攻擊。 “令人驚訝（或者不是？），我們很快發現，在默認配置下，sslvpn沒有得到應有的保護，很容易受到MITM攻擊。Fortigate SSL-VPN客戶端只驗證CA是由Fortigate（或其他受信任的CA）頒發的，因此攻擊者可以輕鬆地將頒發給不同Fortigate路由器的證書呈現出來，而無需升起任何標誌，並實施中間人攻擊。我們在幾分鐘內搜索並找到了20多萬家易受攻擊的企業。” 專家指出，Fortigate SSL-VPN客戶端只驗證CA是由Fortigate或另一個可信CA頒發的，這使得攻擊者可以出示頒發給不同Fortigate路由器的證書來實施中間人攻擊。 主要問題與自簽名SSL證書有關 Fortigate路由器附帶一個由Fortinet簽名的默認SSL證書，這是一個自簽名證書，其中包含路由器的序列號作為證書的服務器名稱。 什麼是自簽名SSL證書？ 自簽名SSL證書，一般是指由不受信任的任意機構或個人，使用工具自己簽發的SSL證書。這些不受信任的機構和個人因為不受任何第三方的監督和審核，所以可以隨意簽發自簽名SSL證書，但其簽發的SSL證書也不被瀏覽器和操作系統所信任，所以經常被不法分子用於偽造證書進行中間人攻擊。 自簽名SSL證書容易被假冒和偽造 因為自簽名SSL證書是可以隨意簽發的，如果你的網站使用的是自簽名SSL證書，那不法分子完全可以通過偽造一張相同的自簽名證書，用於製作假冒釣魚網站，這使得網站用戶無法分辨出真假網站，上當受騙。 而第三方權威機構在簽發SSL證書時，需要對申請企業的真實身份進行驗證，不存在隨意簽發SSL證書的現象，不法分子難以偽造假冒。而部署了受信任的SSL證書的網站，用戶在訪問網站時瀏覽器便會識別SSL證書的真實信息和證書狀態，如果網站SSL證書配置的域名與實際的域名不符，或者出現證書已過期等其它情況時，瀏覽器都會提醒用戶“此網站安全證書存在問題”進行警告，令假冒網站無處藏身！ 專家強調，Fortinet的客戶端根本不驗證服務器名稱，這意味著任何由Fortinet或任何其他可信CA頒發的證書都將被接受。攻擊者可以將流量重新路由到其服務器，顯示自己的證書，然後在攻擊的視頻PoC下解密流量。 不幸的是，Fortinet沒有解決該漏洞的計劃，它建議用戶手動替換默認證書，並確保連接不受MitM攻擊。 目前，當用戶使用默認證書時，Fortinet會發出警告。