微服務許可權

『壹』 為什麼選擇Spring Boot作為微服務的入門級微框架

『貳』 Mⅰcroservice Architect是什麼意思

你好同學，這個直譯過來是「微服務架構師」的意思，我不是太明白這個意思的，謝謝。

『叄』 微服務匯流排有哪些內容

學校很多跨部門、跨業務系統的應用需求，數據格式不統一、介面標准不統一，業務流橫向互通不方便。微服務匯流排促進業務系統橫向互通，可觀可控可分析，極大降低系統間耦合度，提高系統間對接的效率，為後續應用擴展提供便利。功能包括：服務協議標准化（非HTTP restful服務標准化為restful服務）、服務注冊、服務發現、服務許可權控制、服務日誌、服務監控、服務配置管理等。

『肆』 內部微服務系統之間調用是否需要安全認證嗎

想要為開發工程師們開發一個既能滿足REST約束條件和原則又不像OAuth OAuth 那樣復雜 the complexity ，僅僅使用簡單的傳值語句或者其它簡單但同樣安全的方法就能實現的web API? 聰明人會有聰明的想法… 問題 直接通過HTTP literally passing the credentials over HTTP以文本方式傳輸鑒權信息可能會被破譯; 尤其在 Gawker incident, 再以文本或是弱加密的方式傳輸鑒權信息是非常不安全的做法 weakly-hashed anything is usually a bad idea. 即便是使用哈希加密後還是很有可能被人根據彩虹表 Rainbow Table破譯出與用戶名匹配的密碼（個別案例） 這可該怎麼辦，真是郁悶… 也許你又會想到很多公共的API popular public APIs在請求中採用雙數據的模式：一個公有值一個（最好是有）只有屬主能訪問的私有值。 」還是有點不對!」這不跟原來（用戶名密碼模式）文本模式差不多麼，還是可能會被（嗅探器）破譯。 這時候你可能准備放棄並採用OAuth模式了，但仍堅信必有某種簡單方法能實現公用webAPI安全訪問私有鑒權信息。 解決方案 連續2天的Peyote實驗後（你可能會找到更好的放鬆辦法），結論終於呈現在你眼前：Amazon是擁有最大的、使用最多的在線網路API的網路服務之一，並且根本不支持OAuth！ 經過一個下午長時間的狂想之後，你最終敗下陣來，並看到Amazon是如何保持API請求安全的。你不清楚為什麼，但讀完整頁關於如何為Amazon網路服務裝配一個請求後，你依然覺得不完全合理。這個「簽名」和什麼連在一起？代碼示例中的「data」參數是什麼？這樣，你會繼續查找關於「安全API設計」的文章。。。 當遇到其他人問同樣的問題時，你看到一些指出"HMAC"或其他事物的優秀回復，但還是不太確定。 你找到其他鼓勵你使用「HMAC」的文章並且你正H-FINE地使用它，如果有人將「HMAC」解釋成簡明的H_ENGLISH的話。 你的確偶遇了一個有道理的蒸餾的基本概念，它是這樣一簡明的英語描述的： 一個伺服器和客戶端知道一個公鑰和一個私鑰；只有伺服器和客戶端知道私鑰，但每個人都知道公鑰。。。但不關心別人所知道的。 一個客戶端生成一個唯一的HMAC（哈希）表示它到伺服器的請求。通過把請求數據（參數和值或XML/JSON或任何它計劃發送的數據）以及請求數據的散列blob和私鑰結合來實現。 客戶端隨後將這個HASH以及所有它將要發送的參數和值一並發給伺服器。 伺服器接到請求，並使用與客戶端相同的方式重新生成自己獨有的基於提交值的HMAC（哈希）。 然後，伺服器比較這兩個HMAC，如果相同，伺服器就信任這個客戶端並執行請求。 這似乎很直截了當。最初讓你困惑的是，你以為原始請求是經過加密傳送的，但實際上，HMAC方法所做的一切只是使用只有客戶端和伺服器才知道的私鑰將參數生成為一些獨特的校驗和（哈希）。 隨後，客戶端將這個校驗和及原始參數和值發給伺服器，然後伺服器復核校驗和（哈希）以確定它接受客戶端所發的請求。 因為根據假設，只有在客戶端和伺服器知道私鑰，我們假設如果他們的哈希匹配，那麼它們會互相信任，以至伺服器隨即正常處理這個請求。 你知道在現實中，這就相當於某人過來對你說：「Jimmy讓我告訴你把錢給Johnny」，但你不知道這個人是誰，所以你要伸出手去試探他，看看他是否知道這個秘密握手。 如果三次握手證明無誤，則通訊繼續進行，否則中斷通訊。. 你明白了大概是怎麼回事，但還是想會不會還有更好的方法呢？還好，有tarsnap網站 tarsnap幫你答疑解惑。看看亞馬遜是如何解決簽名認證問題的Amazon screwed this up with Signature Version 1. 看完了亞馬遜的web service是如何鑒權的，re-read how Amazon Web Services does authentication 講的確實有道理，整個流程如下: [客戶端]在調用REST API之前，首先將待發送消息體打包, combine a bunch of unique data together(websevice端將要接收的數據) [客戶端]用系統分派的密鑰使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的數據). [客戶端]向伺服器發送數據: 用戶身份認證信息例如,用戶ID，客戶ID或是其他能別用戶身份的信息。這是公共API，大家都能訪問的到(自然也包括了那些居心叵測的訪問者)系統僅僅需要這部分信息來區分發信人而不考慮可靠與否(當然可以通過HMAC來判斷可靠性). 發送生成的HMAC碼. 發送消息體（屬性名和屬性值），如果是私有信息需要加密，像是（「mode=start&number=4&order=desc」或其他不重要的信息）直接發送即可. (可選項)避免重放攻擊 「replay attacks」 o的唯一辦法就是加上時間戳。在使用HMAC演算法時加入時間戳，這樣系統就能依據一定的條件去驗證是否有重放的請求並拒絕. [伺服器端]接收客戶端發來的消息. [伺服器端] (參看可選項)檢查接收時間和發送時間的間隔是否在允許范圍內（5-15分）以避免重放攻擊replay attacks. 提示: 確保待檢對象的時區無誤daylight savings time 更新: 最近得到的結論就是直接使用UTC時區而無需考慮DST的問題 use UTC time . [伺服器端]使用發送請求中用戶信息（比如.API值）從資料庫檢索出對應的私匙. [伺服器端] 跟客戶端相同，先將消息體打包然後用剛得到的私匙加密（生成HMAC）消息體. (參看可選項) 如果你使用了加入時間戳的方式避免重放攻擊，請確保服務端生成的加密信息中擁有和客戶端相同的時間戳信息以避免中間人攻擊man-in-the-middle attack. [伺服器端] 就像在客戶端一樣，使用HMAC哈希加密剛才的信息體. [伺服器端] 將伺服器端剛生成的哈希與客戶端的對比。如果一致，則通訊繼續；否則，拒絕請求! 提示: 在打包消息體的時候一定要考慮清楚，如果像亞馬遜進行簽名版本1中信息識別那樣會面臨哈希沖突的問題 open yourself up to hash-collisions! (建議：將整個包含URL的請求加密即可!) 特別提示:私匙絕對不能在通訊過程中傳遞，它僅僅用來生成HMAC,伺服器端會自動查詢出它的私匙並重新生成自己的HMAC.我來翻譯公匙僅僅用來區分不同的用戶，即使被破解也無所謂。因為此時的消息無需判斷其可靠性，服務端和客戶端還是要通過私匙來加密（比如，前綴、後綴，倍數等等） 10/13/11更新：Chris最近發現 pointed out 如果在HMAC計算中加入了URI或是HTTP請求/回復，攻擊者更易通過更改末端或是HTTP方法來搞破壞。比如，在HTTP POST方法中將/issue/create改成/user/delete。

『伍』 與單塊架構相比較，微服務架構有哪些特點

這就是三十年河東、三十年河西的輪流轉。
當年提出系統結構要內聚，介面要簡潔清晰；如今的微服務正好相反。
所謂微服務就是這個系統的每個模塊都是自成一體的，可以認為其擁有不依賴其他模塊的能力。這樣一來，其可以獨立向外提供服務，甚至可以獨立存在。
我舉個例子，你就懂了：一個網站，又有登錄、又有新聞、又有BBS、又有郵箱，按說這是一個整體，無論登錄許可權，還是瀏覽、交互都是機體的一部分。不能割裂。但在微服務體系下，這些都是獨立的，你可以理解為新聞是一個獨立的割裂存在，BBS是一個獨立的割裂存在，郵件是一個獨立的割裂存在。你懂了嗎？無論是界面、還是業務邏輯、還是數據存取都是各自的獨立一套。不是僅界面割裂，是完全的從上到下的割裂。我覺得例子功能粒度大，也可以功能粒度更小。
你可以想想，每個模塊都可以獨立存在，對外提供功能。甚至其他模塊不存在，某模塊也可以獨立存在，這不是小系統是什麼？而每個這種模塊堆起來一個所謂的系統。那這中間為了保障每個模塊獨立存在的那些功能又得重復多少啊！？你想想吧，每個模塊都有一套維持其存在的這種機制，每個模塊都有這么一堆。這不是重復實現嗎？這還哪有一個系統的概念哪！？簡直就是功能超市。所以，這怎麼說呢？反正就是這么個玩意兒吧！

『陸』 傳智播客Java的課程中大概包含哪些技術

①實戰為主+前沿技術：整體課程中項目部分課程佔到60天，項目中引入時下流行元素，如前後端分離式開發、微服務、容器化部署、DevOps、智能推薦、智能分類等,配以隨堂測試、階段測試、每日作業等教輔工具，讓學生能真正消化與理解所學知識點，並學以致用，真正掌握面向企業的開發方法。
②解決方案式教學：項目中階段引入多達40+的解決方案，如分布式架構、集群部署、微服務、海量數據存儲、分布式日誌、雲存儲、大數據存儲、許可權管理、在線支付等，讓學員真正面對企業中實際問題，成為符合當前企業要求的軟體開發精英。

『柒』 力軟敏捷開發框架怎麼樣啊，用起來如何

力軟的開發框架用起來也不錯，簡單，是.NET語言，適合做一些生產和OA 協助的；
目前主流的還是JAVA；並且在部署上也上升一個台階。從單機部署，到雙擊部署，集群部署，微服務部署，容器部署等多元化的支撐和適配，不只是口頭說過的支持就好，myapps的微服務在杭州的項目中，直接落地K8S和容器部署，doc部署多種方式，來協助企業做好規劃和顆粒度的成長，。目前需要做好調整和配置的思路整體規劃，適配未來的緩存機制和隊列部署以及負載均衡的機制，才可以通過中間件直接實現相關的效果；
所以未來的發展趨勢也是主要考評標准，力軟的客戶群體還是挺穩定，產品線在北方的銷量還是持續上升的。只是不知道部署上是否支持微服務和容器部署，這個找機會體驗下產品，交流下他們的部署方式才好有更加優質優良的推薦
管理顧問，每天成長一點點，努力成就自己的優秀。

『捌』 Java開發需要哪些技術

作為一個Java開發人員，最百大的挑戰就是不斷更新了解新的技術。在時代的變化中，主流技術的掌握也是一門持久的功課。
1、微服務技術
微服務架構主要有：Spring Cloud、 Dubbo、 Dubbox等，以 Dubbo佔比最高，可度達26%，微服務網關技術，使用問springcloud-zuul的程序員佔比最高。
2、遠程調用技術答
使用RPC框架的程序員中， 使用Dubbo的人數占前端要學好必須每天堅持學習。為了方便大家的交流學習，也是創建了一個群每天都有分享學習方法和專業老師直播前端課程，這個扣裙首先是132 中間是667 最後是127 前端學習零基礎想要學習的同學歡迎加入，如果只是湊熱鬧就不要來了!!!比最高，其次為 bbox、gRPC、hessian也具有一定的使用比例。內
3、開發技術
多數程序員在工作中使用的開發技術為許可權管理和消息隊列。1/4的程序員在工作中使用的開發技術為報表技術、分布式緩存技術和負載均衡解決方案。
4、許可權管理技術
shiro的使用比例最高，其次為spring security和自定義框架。
5、消息隊列技術
消息隊列技術主要有：ActiveMQ、RabbitMQ和Kafka。RocketMQ的使用人數較少容。

『玖』 微服務開發中的數據架構應該怎樣設計

前言

微服務是當前非常流行的技術框架，通過服務的小型化、原子化以及分布式架構的彈性伸縮和高可用性，可以實現業務之間的松耦合、業務的靈活調整組合以及系統的高可用性。為業務創新和業務持續提供了一個良好的基礎平台。本文分享在這種技術架構下的數據架構的設計思想以及設計要點，本文包括下面若干內容。

• 微服務技術框架中的多層數據架構設計

• 數據架構設計中的要點
  

• 要點1：數據易用性

• 要點2：主、副數據及數據解耦

• 要點3：分庫分表

• 要點4：多源數據適配

• 要點5：多源數據緩存

• 要點6：數據集市

為了容易理解，本文用一個簡化的銷售模型來闡述，如下圖。圖1顯示了客戶、賣家、商品、定價、訂單的關系（這里省略支付、物流等其他元素）。

圖1 銷售模型

在這個銷售模型中，賣家提供商品、制定價格，客戶選擇產品購買、形成銷售訂單。根據微服務的理念設計，可以劃分為客戶服務、賣家服務、商品服務、定價服務、訂單服務，以及公共服務（比如認證、許可權、通知等），如圖2所示。



圖9 數據緩存

要點6：數據集市

數據集市是一個很大的話題。當現有的數據不能簡單地通過幾個表數據關聯以及簡單加工後就可以供業務使用的時候，就需要考慮構建數據集市。數據集市以數據運用的觀點來分析加工數據，通過多源數據的導入、清洗、加工、視圖做成等一系列的數據操作後，為業務提供可用的、穩定的數據源。例如，對銷售分析中、什麼樣的客戶喜歡什麼樣的商品、價格對銷售金額的影響、銷售金額跟地區日期的關聯關系等多維度分析，就要用數據集市的概念，如圖10所示。

圖10 數據集市

數據承載著信息，好的數據架構設計會使業務系統變得更加流暢、更加容易理解和維護。本文只是總結一些在實際工程中的體會，供大家分享。如果有不足之處、也請大家補充、賜教。

（此文轉載至GitChat技術雜談）