資安

一、 前言： “高可用性”（High Availability）通常來描述一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。所以當我們一說到高可用，我們滿腦子都是以負載均衡為主心骨搭建的拓撲圖，以他為中心，從單節點拓展為多節點，消滅單點故障。但隨著我們業務架構越來越龐大複雜，那麼要考慮的就不再只是服務器維度的高可用了。接下來，我來給大家介紹一下不同維度的“高可用”在架構上是如何實現的。 二、 通用高可用 很多人在搭建業務的時候喜歡用一臺高性能服務器搭建所有業務所需的應用和環境。比如服務器上搭建Nginx、會員系統、訂單系統、自建數據庫等等。這類搭建的初衷大概有簡單省事、預算不足、初期業務量小感覺夠用等因素。 這些困難業主要集中在業務上線初期，都是很現實的問題，不過隨之帶來的是更加現實的困難。性能瓶頸很快到來，後期調整架構會因越來越大的數據量和停服帶來收益減少等等問題。 所以業務初期搭建一個基礎高可用框架，日後根據需要逐漸添加功能。 A、後期業務增加後我們再根據需要逐步擴容，例如數據庫讀寫壓力大了，我們用Redis、數據庫讀寫分離等手段。這樣擴容不用複雜的操作，不用長時間的停服遷移重要的數據信息。 B、再後來業務量進一步擴大，需要短信服務、需要組網、需要安全防護等等，都可以靈活拓展。所以對於服務器層面來說，一開始就搭建一個高可用架構是至關重要的。 三、 進階高可用： 容災方面： 通常對於一個普通的APP、門戶網站、內部系統等等業務，通用高可用已經足夠了。但為了實現客戶們日益提高的對體驗感的的高要求，工程師們不知踏平了多少坑以後實踐出了與之對應的高級高可用架構。這種架構不再針對某一個業務集群做高可用，而是以業務為維度。舉個例子當某一個地域的業務不可用時，能有其他地域的備用集群頂上。 客戶體驗感： 當業務做大到一定程度，客戶群體就不僅僅侷限於一個市或者一個省，乃至一個國家。這時候，因為客戶離業務集群太遠，導致通訊質量不佳，延遲、丟包問題層出不窮。以前我們經常用“三秒”來定義一個網站的好壞，但現在主流網站大多均已採用“1.5秒”來打分了。傳統的單業務節點越來越難滿足了，那就得考慮多節點同時運行承載業務，可通過全局流量來實現。而多節點之間的數據同步可以用阿里雲的雲企業網來實現。 負載均衡從其應用的地理結構上分為本地負載均衡和全局負載均衡。本地負載均衡是指對同地域的服務器群做負載均衡，全局負載均衡是指對分別部署在不同地域有不同網絡結構的服務器群做負載均衡。 多線路智能化解析服務 全局流量管理利用DNS智能解析和應用服務的運行狀態健康檢查，將用戶訪問定向到最合適的IP地址，使訪問用戶獲得最快捷、最流暢的體驗。 […]

簡介 java中為了保證共享數據的安全性，我們引入了鎖的機制。有了鎖就有可能產生死鎖。 死鎖的原因就是多個線程鎖住了對方所需要的資源，然後現有的資源又沒有釋放，從而導致循環等待的情況。 通常來說如果不同的線程對加鎖和釋放鎖的順序不一致的話，就很有可能產生死鎖。 不同的加鎖順序 我們來看一個不同加鎖順序的例子： public class DiffLockOrder { private int amount; public DiffLockOrder(int amount){ this.amount=amount; } public void

  Java屬於編程語言的核心語言，很多公司都在用Java，Java語言開發優勢顯著穩定性好，在服務器端Java發揮高性能、安全穩健的特性。 2019年Java崗位需求仍呈現持續上升趨勢供不應求，2020年Java就業前景也會不錯。 Java工程師的需求佔全部需求量的60%~70%，3~5年開發經驗的Java工程師薪水年薪10~30萬元，Java的發展前景好，像百度、京東、阿里巴巴等都在使用Java開發。 在各大招聘網站上搜索市場需求量大，可直觀看出Java程序員、Java工程師的崗位有很多，薪資待遇普遍偏高。 Java應用廣泛，PC、數據中心、遊戲控制檯、科學超級計算機、移動電話和互聯網等行業都離不開Java。 01 Java程序員市場需求缺口大 近年中國在移動互聯網這塊發展非常迅猛，各種創業公司、小團隊如雨後春筍般冒出來，對安卓開發、PHP、java、web的需求變大。但存在人才發展跟不上市場的需求的現狀，相對應的給優秀Java人才開出的薪資待遇隨之水漲船高。 從第三方平臺統計的數據可以看到，Java工程師在2019年平均月薪接近20K，其中20K-30K的薪資佔比為30.3%。 崗位需求方面，從100offer招聘網發佈的各技術類崗位企業面邀數佔比可以看出，Java工程師企業需求為第一位，佔比60%，同比增長了11%。由此可見，Java崗位需求仍然呈現持續上升趨勢，供不應求。 02 Java程序員門檻高 要求計算機技術或是相關專業的大學生，Java對從業人員素質，計算機相關行業會了解最基本的互聯網的相關知識，以及簡單的語言基礎;從事Java開發行業，招聘公司對學歷有要求，大部分要求是專科以上。 並不排除有非計算機專業的從事Java行業的開發人員，但是萬事開頭難很多人抱著很大的希望去學習，學習過程中遇到的困難越來越多，慢慢就放棄了，因此有一部分人在入門的路上就淘汰了。學習前就要下定決心，學習不能輕易放棄。 03 Java崗位晉升方向多 大部分Java從業人員起初都是從初級工程師開始入門，隨著工作年限、工作經驗的不斷增加，從初級工程師進階到中級工程師。 隨著自身開發能力的不斷提高，開發項目的不斷積累從一個從中級工程師到高級甚至是開發組長的一個跳躍，在此基礎上再往更高的項目經理、項目總監職位晉升的話就不只是需要嫻熟的開發能力，溝通協調能力也是不可或缺的。 最後如果想要成為Java架構師或者是企業CTO，需要不斷加強自身技能的基礎上具備良好的駕馭管理開發團隊能力，有良好的人格修養，提升個人能力才能將企業向更好的方向帶領。

基於Patroni的Citus高可用環境部署 1. 前言 Citus是一個非常實用的能夠使PostgreSQL具有進行水平擴展能力的插件，或者說是一款以PostgreSQL插件形式部署的基於PostgreSQL的分佈式HTAP數據庫。本文簡單說明Citus的高可用技術方案，並實際演示基於Patroni搭建Citus HA環境的步驟。 2. 技術方案 2.1 Citus HA方案選型 Citus集群由一個CN節點和N個Worker節點組成。CN節點的高可用可以使用任何通用的PG 高可用方案，即為CN節點通過流複製配置主備2臺PG機器；Worker節點的高可用除了可以像CN一樣採用PG原生的高可用方案，還支持另一種多副本分片的高可用方案。 多副本高可用方案是Citus早期版本默認的Worker高可用方案（當時citus.shard_count默認值為2），這種方案部署非常簡單，而且壞一個Worker節點也不影響業務。採用多副本高可用方案時，每次寫入數據，CN節點需要在2個Worker上分別寫數據，這也帶來一系列不利的地方。 數據寫入的性能下降 對多個副本的數據一致性的保障也沒有PG原生的流複製強 存在功能上的限制，比如不支持Citus MX架構 因此，Citus的多副本高可用方案適用場景有限，Citus 官方文檔上也說可能它只適用於append only的業務場景,不作為推薦的高可用方案了(在Citus

問題 使用過阿里雲ECS雲盤快照的朋友，大概都有這種感觸：它雖然功能穩定，性能強大，但是易用性有待提高，體現在：1，ECS，雲盤，快照，策略等相互強關聯的概念，分散在幾個菜單中，新手不容易上手。2，不能一眼看出來，哪些ECS在哪個時間段保護了哪些雲盤，呈現上不直觀。3，不能很快定位到某個時間段的可恢復點，要一天天找來找去，回滾過程比較繁瑣。 解法 良好的用戶體驗可以直接提高新用戶操作的意願和成功率，特別是當前備份/恢復是強需求，如果可以實現一鍵快照，恢復的時候可以迅速定位到可用恢復點，那不僅能給企業提效，更重要的是為數據安全保駕護航，為數據恢復爭分奪秒。 所以阿里雲災備服務（HBR）推出了以提高用戶體驗為首要目的的雲盤快照服務，做到了三個一：一鍵快照/一覽歷史/一鍵恢復。筆者更冒死預告：快照長期備份功能即將上線，提供強大的數據壓縮重刪以及多版本功能，強力保護您的數據（以下備份部分僅做預告，敬請期待）。 一鍵快照 首先進入HBR控制檯，點擊“添加ECS”後進入新手嚮導頁面。嚮導圖形化集中化的展示了要保護的資源和策略，形象表示了數據從數據源->快照->備份的流動過程。用戶可以在一個頁面上完成所有配置，再也不用跳來跳去。配置完成之後點“確定”即創建了週期快照計劃（或者立即進行快照），同時將這臺ECS添加到“被保護ECS列表”頁面，下次用戶登錄控制檯就能看到。1，被保護的ECS：直接選擇一個ECS，指定要保護整機還是勾選某幾塊雲盤。整機保護會一次性保護此ECS所有的雲盤（包括後期新增的雲盤）。2，快照策略：指定週期性的做快照還是僅僅立即做一次快照，同時可以配置快照過期時間。3，備份策略（敬請期待）：是否在快照完成之後創建一個備份，存儲到災備庫中。此備份有重刪壓縮，能即時訪問，可以用於文件級別恢復。 一覽歷史 當用戶按照上文一鍵保護了ECS之後，在“被保護ECS列表”可以看到這臺被保護的ECS，展開它可以看到保護的歷史時間軸，這個圖直觀展示了這幾個方面：1，保護對象：可以是查看整機保護情況，或者並行展示所有被保護的雲盤。2，時間區間：可以查看任意時間段內產生的快照，每個快照以一個圓點表示，直觀展示了保護策略和可供恢復點分佈。用戶可以鼠標拖選任意時間段放大查看，方便選擇到某個恢復點。3，保護類型：可用恢復點是快照還是備份，繪製到兩個不同的數據線上以示區分。 一鍵恢復 這裡的“恢復”特指快照的回滾和克隆，恢復邏輯也很自然：在要恢復的ECS操作菜單直接點擊回滾或者克隆，就能開始恢復流程。或者在快照歷史時間軸，直接點擊要恢復的某個時間點（圓球圖標），也能啟動恢復流程！這裡有2個操作：1，克隆：根據恢復時間點的數據新建出ECS或者雲盤。要特別強調的是，在歷史時間軸的“整機視角”，如果恢復點包含系統盤，則可以直接創建一臺包括恢復點保護的所有云盤數據的ECS。2，回滾：將恢復時間點的數據覆蓋到被保護的ECS或者某個雲盤。注意只有在ECS關機的情況下才能操作成功。 計劃、任務管理 最後，HBR整機保護服務提供統一的計劃管理和任務管理界面（包括保護任務和恢復任務），給用戶提供了靈活的保護計劃和精準的任務監控：1，計劃列表：可以暫停/繼續/刪除某個ECS的保護計劃，可以編輯時間策略，修改保護盤等，還可以立即執行一次保護任務。2，保護任務：可以查看保護計劃的執行情況，細分到每個雲盤的保護進度。3，恢復任務：可以詳細查看從哪個源，恢復了什麼時候的數據，有多大數據，到哪個目的地。 總結 所謂一圖勝千言，通過上面對比說明，相信大家可以感受到阿里雲災備服務為提高用戶ECS快照使用體驗作出的誠意。還等什麼，快來給你ECS的小盤盤們愉快的拍個集體快照吧！ 注：生成的快照會按照收費標準進行收費，收費模式請見官網塊存儲價格頁面。

虛擬網絡控制檯（VNC）是一個圖形桌面共享軟件，允許您使用鍵盤和鼠標遠程控制另一臺計算機。系統環境服務端：Centos7.7 Minimal客戶端：Windows10客戶端VNC-Viewer 6.20下載地址：https://www.realvnc.com/en/connect/download/viewer/安裝桌面環境本實驗中安裝的系統沒有安裝桌面環境，我們需要自己安裝，如果已經安裝桌面了清跳過這一步。Centos7提供了”Cinnamon Desktop”,”MATE Desktop”,”GNOME Desktop”,”KDE Plasma Workspaces”,”LXQt Desktop”,”Xfce”讓我們安裝。 下面的命令列出可用環境組： [root@localhost ~]# yum grouplistLoaded plugins: fastestmirrorThere is no installed groups

​2020年是特殊的一年，受疫情的影響，人們的工作和生活方式已悄然發生改變，遠程辦公、在線教育、在線醫療的激增，各行業都經歷著一場“抗壓測試”。數字化轉型已然是大勢所趨，成為這場測試中晉級突圍的最佳方案。隨著大數據，雲計算和5G新技術的引入，企業IT基礎設施架構也發生了顯著的變化： – 企業核心應用“雲化”，包括企業內部應用雲化以及外部應用的互聯網-業務場景“邊緣化”，越來越多的數據處理和計算下沉到邊緣節點完成-辦公場景“多樣化”，移動辦公、遠程辦公、總部/分支機構協同辦公 這種變化對傳統IT基礎設施的安全帶來了全新的挑戰，企業原先的邊界正在被打破，傳統的硬件安全方案已經無法滿足企業數字化轉型中的防護要求。 SASE（Secure Access Service Edge），安全訪問服務邊緣 ，這種架構將更能適應邊緣計算、雲服務和混合雲等IT環境，更快速、更安全、更便捷的幫助企業完成數字化轉型。 —- Gartner ，2019 因此，在剛收官的雲棲大會上，阿里雲正式發佈“雲原生SASE解決方案”， 將核心原生安全能力與網絡能力融合，為雲上用戶提供了一個基於阿里雲基礎架構的SaaS化安全服務平臺。該方案基於雲的天生動態擴展能力，支持安全防護能力實時敏捷、彈性伸縮；依託阿里雲遍佈全國的數據中心和邊緣計算節點，實現網絡就近接入，降低延時，確保安全效果；更基於阿里雲身份認證服務，構建全新零信任訪問架構，極大降低內部資產和系統暴露面，打造更安全辦公體系。因此，阿里雲原生SASE解決方案給用戶提供的是一個統一安全管理能力，不僅僅覆蓋雲上資產和應用的安全，也可以更好的管理企業辦公網的安全。 基於SASE架構的CSAS安全訪問服務近日，作為阿里雲SASE架構的核心產品，雲安全訪問服務（Cloud Security Access Service，簡稱CSAS）正式上線公測。該產品支持企業對員工內網應用的使用和互聯網訪問進行統一平臺化安全管理。且阿里雲CSAS支持與SD-WAN的深度整合，如此可以幫助阿里雲上企業覆蓋更多樣化場景，比如企業總部和分機構/門店之間的安全管理，還有移動辦公以及遠程辦公的安全等。 CSAS安全訪問服務，基於阿里雲原生優勢，呈現高可用、全覆蓋、低延時、“0”觸感四大特質，並支持四大核心數字化場景： 場景1：**總部/分支機構、門店辦公安全低成本，高效率、統一平臺化管理**今年3月，盒馬宣佈將在全國範圍內新開出100家盒馬鮮生大店。相關媒體也提到，城市化發展需要門店這種區域化、分散化經營模式，這將成為一種新的趨勢。與此同時遍佈全國範圍內的金融機構，也同樣存在這種總部和大量分支機構協同的狀態，如此對於安全管理提出了更高的要求，如何最大化的提升安全效果，如何對分支機構進行統一化安全管理，成為重點關注問題。

本文關鍵字：啥是真正的黑群，壓縮skynas磁盤佈局為5G內 在《dsm as Deepin mate(2)》中，我們講到了使skynas鏡像脫離aliyun ecs真正能運行起來的方法。但是我們用的是倒敘的手法，我們還沒到得到安裝鏡像，這裡繼續。講解離線創建和編輯純淨鏡像，使之能像普通黑群一樣啟動，完成安裝/升級的方法。 Ps:啥是真正的黑群 ————所謂黑群暉,是由於群暉基於linux gpl要求開源了早期內核和toolchain在sourceforge：http://sourceforge.net/projects/dsgpl/files/，而它的rd.gz,pat升級/安裝包是很容易解包打包的https://github.com/andy928/synochecksum。因此。各種黑群技術有機會修改zImage,rd.gz和重新打包定製pat。你可以在這裡定製內核插入你的驅動，作各種腳本增強，使群暉適用於更多機型，甚至通用硬盤。故，其實正真被黑的部分並不是bootloader。正真被黑的應該是部分內核zImage與位於initrd ramdisk中的各種外掛模塊。至於系統中的安裝包/升級包中的正常具體邏輯，是不需要破解的。雖然如此，大部分黑群版本命名大都是xxxboot之類。具體技術方面，（1）破解的第一關是rd.gz中的synobios：群暉是通過一個叫做synobios.ko的外掛模塊集中處理硬件綁定問題的。一旦破解了它,很容易解除硬件綁定關係。所謂的破解，主要就是改一下這個接口的代碼，使他在黑群暉的硬件上也能返回一個合法的機型代碼（例如DS3612xs的代碼是42）。因此，大家現在所安裝的黑群暉，實際上synobios.ko文件已經修改過了，鏡像pat也用的是重新打包過的pat，synochecksum-emu1 hda1.tgz rd.gz updater VERSION zImage >checksum.syno這裡有一個對pat內文件驗證打包的過程。(2)破解的第二關，群暉在sourcefourge的開源內核驅動僅支持官方，本身也是有點錯誤的，需要一定定製，加入自己的驅動，直接編譯後在引導系統的時候會出現很多錯誤，例如加載synobios時候出現找不到符號的錯誤、synoacl實現並沒有完全開放等等。因此，需要對synology開放的內核代碼做一些修改，目前網上能夠找到的對內核的修改只有舊內核的(3.2.11等）。加入自己的驅動，等等。（3）還有一些邊角的破解或增強，如修改u盤vid和pid,填寫正確的U盤 VID和PID可以在DSM界面隱藏U盤，修改sn和mac地址可以用於”洗白”。可見sn破解是無關緊要的，除非你要用上官方的服務如quickconnect,ffmpeg縮略生成等（見前文後面，本地驗證版黑群，官方只是沒有對這些假sn開刀而已）。http://xpenology.com/wiki/en/building_xpenology可以說是一篇最詳細和權威的資料（編譯內核的內容，還包括了synobios的破解和rd.gz的製作，etc..），不過它是是針對4.1的老版本的。不過其用於指導黑群製作的思路是不變的。視上面二方面，加入了不同驅動，作了不同增強，因此有很多黑群版本，雖然定製synobios是不可避免的，但有的版本，如gnoboot支持使用官方的PAT文件（依然是xpenology的思路），gnoboot編寫了一組腳本，巧妙的實現了在rd.gz引導系統後自動替換需要破解的文件，不僅如此，gnoboot還包含了大量的驅動，並且可以很方便的加載和卸載驅動。————— 問題回到出發點，對於skynas,破解目標是什麼?對應上面提到的(1)（2）（3）有哪些地方需破解呢？第一個問題，不經過破解直接運行的結果，就是用你提取的安裝鏡像換機安裝時，不會啟動sda5中的系統安裝無法繼續，而是進入web assit重裝界面（即用當初收費鏡像機dd出來的機器鏡像，換機後也有綁定過期驗證不通過退回webassit重裝界面），這個綁定在哪？是不是驗證？這就是第二個問題。 作初步猜想，可能在grub的那個checksum（zimage,rd.gz,update.pat/hda1.tgz三個都是阿里雲綁定的因為其內都有aliyun_xxx相關的腳本文件,不排除是這個原因導致的安裝驗證不通過。rd.gz/synobios應該不需要破解因為都是阿里雲機。那麼那個checksum呢？），也有可能在sn綁定（因為skynas是個在線機器,有先sn網絡驗證後安裝的條件，不過群暉並不常用sn驗證安裝過程,物理機上的黑群boot通過了就通過了）。

在當下數據為王的時代，客戶的業務數據是一個企業的核心資產，各個行業客戶都在不斷追求在其使用的數據庫上有更為強大、細粒度的數據備份恢復功能，以應對各樣的數據丟失、業務邏輯錯誤帶來的商業風險。例如，在遊戲行業裡，有大量客戶存在“遊戲回檔”的實際需求，以應對運營或故障風險。再例如，2020年某上市公司出現刪庫跑路事件，公司市值遭到嚴重打擊。對於上述情況，傳統的定時或手動備份的數據由於存在備份時間點與黑天鵝事件之間的時間差，因此均不是理想完備的解決方案。對於防範上述數據風險，最理想的功能是，數據能夠以秒級顆粒度恢復至黑天鵝事件發生的瞬時時間點上。 在傳統關係型數據庫中（如Oracle）提供了數據閃回功能，幫助客戶完成數據的按時間恢復。而在主流的高速緩存產品Redis、Memcached上卻鮮有類似的功能，箇中原因主要是考慮到作為緩存產品，其中的數據可以丟失，而通過背後配備的持久化、事務性的關係型數據庫可以對緩存進行重新加載。但是，隨著大量客戶對於低延遲的業務應用性能要求不斷的提高，對於一些對延遲要求極高的場景下，例如遊戲行業，越來越多的客戶選擇化簡架構，將Redis直接作為內存數據庫來使用，這便對Redis的數據安全可恢復提出了更大的挑戰。阿里雲Redis作為行業內的領軍產品，擁有國內強大的Redis產品系列，在託管社區Redis版本的同時大力發展自主研發、兼容Redis協議增強型鍵值存儲產品Tair（阿里雲Redis企業版）。 其中“更安全”是阿里雲Redis向廣大客戶提供服務的重要部分，針對上述客戶訴求，阿里雲在Tair中的性能增強版上特別推出了數據閃回功能，幫助客戶實現在其指定時間點上恢復指定Redis實例數據的能力，提前為客戶可能出現的風險準備好一劑“後悔藥”。功能示意如下圖所示： 使用這個能夠幫助用戶穿越數據變遷的黑科技只需簡單幾步。 開通阿里雲Redis企業版性能增強版實例 開啟數據閃回功能 正常讀寫Redis數據庫 一旦發生即時數據恢復要求，選擇對應實例和欲恢復的時間點，產生新實例 切換應用連接的實例地址 下面以一個簡單的示例演示：首先，我們先對一個阿里雲Tair實例寫入一些數據，寫入腳本如下： % cat preparerepldata.sh #!/bin/bash echo “started at: `date +%m%d%H%M%S`” for

在上一篇文章《利用雲存儲網關的SMB共享搭建windows FTP服務器訪問對象存儲OSS》當中，我們為大家介紹了在windows上如何利用系統自帶的IIS服務來搭建一個FTP服務器來訪問對象存儲OSS，考慮到很多用戶是使用的第三方的FTP 服務器，今天我們就以比較常見的fileZilla Server 為例，介紹下如何使用FileZilla Server版本來使用雲存儲網關的SMB共享。 首先在準備好了雲存儲網關的SMB共享，並綁定bucket資源後，在需要搭建的FTP server的windows服務器上嘗試使用雲存儲網關配置的SMB用戶來訪問共享。 1.1 在windows 資源管理的地址欄中鍵入雲存儲網關控制檯上提供的SMB共享地址。 1.2 在彈出的鑑權窗口輸入在網關控制檯配置的用戶名及密碼，在本示例中我們使用iisadmin這個網關控制檯上配置的用戶。 1.3 檢查基本的創建文件/目錄等操作是否正常。 檢查在windows服務器上檢查訪問共享沒有問題後，我們需要在windows上創建一個同網關控制檯上配置了共享權限用戶同名的本地用戶，並配置相同的口令。雲存儲網關控制檯用戶名 windows 創建相同用戶名密碼 我們在windows的服務管理中，將安裝的FileZilla服務（FileZilla Server