紅魔電競平板評測：大屏幕硬實力
前言：三年的疫情因為要上網課的原因激活了平板市場，如今網課的時代已經過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環境來了。也就是面對著這種殘酷的
微服務的好處有好多，易于擴展，發布簡單，技術異構，便于重構等等，但今天我們的主題不是說好處，而是我們需要知道微服務同樣也會帶來痛，我覺得我們更要重視，提出問題，定義問題比解決問題更加的重要。
微服務的難點在于無法對一些特定職責進行清晰劃分，比如這個職責歸屬于A還是屬于B，舉例如下：
Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
康威是個程序員，他提出:設計系統的組織在設計系統的時候，會設計出基于這些組織的溝通結構的系統。
上面的例子說明，在現實的場景中，微服務職責劃分會受到太多因素的影響。我們需要慎重考慮。
舉例一個新零售系統，剛開始只有登錄和信息管理。這些功能放在一個服務就行了，隨著加盟商的加入，因為加盟商準入，開店，退出都設計費用問題，因此我們又需要增加財務功能，比如應收、應付、實收、實付，退款，對賬等，緊接著又要對加盟商員工管理(員工管理、部門管理、權限管理等)返點、加盟商子門店管理等功能，而此時的加盟商管理系統只有一個服務，你覺得合適嗎？
一般來說，在設計新功能之前，我們會遵循一個大致的原則：根據新的微服務的大小，安排3-4人設計即可。
在對微服務拆分的時候，我們還需要考慮另外一個因素---績效。大家都知道，開發人員的績效很難實現量化，而微服務可謂是一個難得的可量化指標。
雖然我們不能拿微服務數作為KPI，但是開發人員在闡述個人工作量的時候會提及服務數。然后潛意識里就會細化微服務的個數，所以我們需要控制服務數，這種方法也可以作為服務拆分的一個逆向操作。
不知道你有沒有碰到過這種情況：每隔幾個月或半年，大領導就會發話讓我們匯報下每個部門的微服務數量、公司微服務總數量、每個微服務都用來做什么等情況。因為企業微服務數較多，所以每次給大領導匯報時，都是長長的一條清單。
在以前的公司，我首先會把公司的整個架構系統全貌搞清楚，之后一旦出現問題，也就容易定位故障點了?？墒亲詮膩淼竭@家使用微服務的公司后，我便再也沒有這樣的沖動了，只要求搞懂自己的一畝三分地就行，如果出現問題臨時學習一下相關系統就好了。
因此，在實際工作中，很難找到這么一個人，他能知道系統整體架構的全貌，這就是微服務的一個痛點。
比如某個團隊做了一個日志自動埋點的功能，它能自動記錄一些特定方法的調用。但是第一個吃螃蟹的團隊使用后，立馬報出了一個 JAR 版本沖突問題，自動埋點團隊又重新設計了一版埋點的 JAR，并去掉了一些特定 API 的使用，最終 2 個團隊終于可以正常使用了。不過呢，第三個使用埋點的 JAR 的團隊又匯報了一個 JAR 版本沖突問題，又開始重復了上面的操作。
后來我們復盤了下，得出結論：重用 JAR 本身沒有錯，錯就錯在我們使用的 JAR 版本太多了，必須改變這個局面。
不過，維護這些小小的重復代碼總比統一排期做重構、統一評審 JAR 版本的成本低得多。
分布式事務是微服務永久的痛，事務出錯，是哪些回滾，哪些不會滾等等問題。
因此在這種情況下，大部分場景下我們不考慮回滾和重試，只考慮Happy Path，如果報錯就記個異常日志，再線下處理。也是So easy！
(6)耗費更多的服務器資源
有時候為了運維更好的定位問題，我們把服務各自分配到每一個節點上，同樣這樣就會耗掉很多的服務器。
總結：
本文鏈接：http://www.www897cc.com/showinfo-26-35884-0.html微服務，其實它也是有很多坑
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號