7月安卓手機(jī)性價(jià)比榜：努比亞+紅魔兩款新機(jī)入榜
7月登場的新機(jī)有努比亞Z50S Pro和紅魔8S Pro，除了三星之外目前唯二的兩款搭載超頻版驍龍8Gen2處理器的產(chǎn)品，而且努比亞和紅魔也一貫有著不錯(cuò)的性價(jià)比，所以在本次的性價(jià)比榜單
有一則頗為滑稽的場景，講述了一位工程師向項(xiàng)目經(jīng)理解釋一個(gè)過于復(fù)雜的微服務(wù)系統(tǒng)是如何工作的，以便獲取用戶的生日，但最終仍然解釋不清楚。
圖片
這一場景準(zhǔn)確地描述了當(dāng)前IT文化的荒謬之處。然而在現(xiàn)實(shí)中，如果你跟面試官講了這個(gè)笑話，你猜他會(huì)怎么看你，大概率你不會(huì)通過面試的。
為什么會(huì)變成這樣呢？我們的目標(biāo)本來應(yīng)該是讓系統(tǒng)正常的運(yùn)行起來，滿足業(yè)務(wù)的需要，但是現(xiàn)在卻變成了要解決根本沒有的問題（微服務(wù)帶來的問題），結(jié)果就是熬了好多個(gè)夜，掉了好多根頭發(fā)，給服務(wù)器運(yùn)營商分了不少錢，結(jié)果呢？
近年來，有幾件事可能導(dǎo)致了當(dāng)前局勢。
首先，大批使用 JavaScript 前端開發(fā)者開始自稱為“全棧”，涉足服務(wù)器開發(fā)和異步代碼，比如node，比如 Vercel 對(duì) React 的魔幻操作。JavaScript就是JavaScript，使用它創(chuàng)建什么不重要， 用戶界面、服務(wù)器、游戲還是嵌入式系統(tǒng)。對(duì)吧？
Node當(dāng)時(shí)還只是一個(gè)人的學(xué)習(xí)項(xiàng)目，早期的JavaScript是服務(wù)器開發(fā)盡量要避免的，或者不可能選擇的語言。但你如果和一些固執(zhí)的 JavaScript、Node開發(fā)者來說，會(huì)遭到對(duì)方的鄙夷。畢竟，這是他們知道的全部，Node之外的世界實(shí)際上是不存在，Node就是唯一的選項(xiàng)，因此這是我們至今要處理的固執(zhí)、教條主義思維的起源。
另外，還有一大批大廠向外輸送的“人才”涌入初創(chuàng)公司或者小公司隊(duì)伍中。用大廠的那一套模式和方法來指導(dǎo)團(tuán)隊(duì)，即使這套模式并不合適。那不是他要考慮的。“我不管，怎么沒有單獨(dú)的用戶服務(wù)呢？將來怎么擴(kuò)展呢，兄弟！”
還有一個(gè)不得不說的事實(shí)，在國內(nèi)凡是面試，必定要問微服務(wù)，從來也不看看線上用戶才多少，開發(fā)團(tuán)隊(duì)才幾個(gè)人。這就導(dǎo)致很多沒有接觸過微服務(wù)的開發(fā)者，愿意在平時(shí)的項(xiàng)目中嘗試微服務(wù)，因?yàn)槟軌蚍e累一些經(jīng)驗(yàn)，方面以后跳槽能拿到更多的錢。
在早些時(shí)候，分布式系統(tǒng)是受到尊重、畏懼和普遍盡量避免的，僅作為處理特別棘手問題的最后手段。一旦涉及分布式系統(tǒng)，就會(huì)變得更具挑戰(zhàn)性、更加耗時(shí)，無論是開發(fā)、調(diào)試、部署、測試。
但是現(xiàn)在卻變得超級(jí)容易了，因?yàn)橛辛烁鞣N各樣的框架和工具，比如docker、k8s，以及像 Spring Cloud、Dubbo 等各式各樣拿來即用的框架。
這里的摘要讓我印象深刻，因?yàn)樗錆M了常識(shí)性的結(jié)論：有一份關(guān)于5年初創(chuàng)公司審計(jì)摘要：那些表現(xiàn)最好的初創(chuàng)公司，通常對(duì)工程學(xué)采取了一種竭盡所能“保持簡單”的方法。純粹為了耍聰明是被鄙視的。相反，那些讓我們感到“哇，這些人真是聰明極了”的公司，大部分都已經(jīng)消失了。
許多初創(chuàng)公司遇到了一種“冒牌綜合癥”的問題。在構(gòu)建直截了當(dāng)、簡單、高性能系統(tǒng)時(shí)，那些一開始沒有使用微服務(wù)的公司，常常會(huì)疑惑“只要一個(gè)Spring Boot單體維護(hù)就可以，由幾個(gè)工程師維護(hù)，還有一個(gè)MySQL實(shí)例，難道系統(tǒng)不應(yīng)該這么做嗎？”。答案是“沒有”。
同樣，有經(jīng)驗(yàn)的開發(fā)者在當(dāng)今 IT 環(huán)境中常常會(huì)陷入自我懷疑和自我否定。好消息是，這可能不是你的問題。
在今天的技術(shù)世界中，一些團(tuán)隊(duì)或開發(fā)者往往假裝他們?cè)谧龈卟l(fā)、超復(fù)雜的系統(tǒng)，但他們可能甚至不知道數(shù)據(jù)庫索引的基礎(chǔ)知識(shí)。我們正處在一個(gè)充滿不合理的過度自信、浪費(fèi)的海洋中，那么真正的騙子是誰呢？
如果你沒有一個(gè)看起來像臭名昭著的阿富汗戰(zhàn)爭戰(zhàn)略圖式的系統(tǒng)架構(gòu)圖，你就無法成長，這種想法是一個(gè)笑話。
圖片
Dropbox、Twitter、Netflix、Facebook、GitHub、Instagram、Shopify、StackOverflow ，這些公司和其他公司都以單一代碼庫開始。其中許多公司的核心仍然是單體。StackOverflow引以為傲的是他們運(yùn)行龐大網(wǎng)站所需的硬件非常少。Shopify仍然是一個(gè)Rails單體，利用了經(jīng)過驗(yàn)證的Resque來處理數(shù)十億個(gè)任務(wù)。
WhatsApp是以Erlang單體和一個(gè)相對(duì)較小的團(tuán)隊(duì)開發(fā)而最終成功的。并一直將團(tuán)隊(duì)人員保持在較小規(guī)模，只有大約50名工程師。每個(gè)Team也很小，由1-3名工程師組成，每個(gè)Team都擁有很大的自主權(quán)。
在服務(wù)器方面，WhatsApp更傾向于使用較少數(shù)量的服務(wù)器，并將每臺(tái)服務(wù)器縱向擴(kuò)展到最大程度。縱向擴(kuò)展就是加強(qiáng)單機(jī)配置，比如增加 CPU、內(nèi)存、存儲(chǔ)等，相對(duì)而言，增加多臺(tái)服務(wù)器叫做橫向擴(kuò)展。
Instagram被以數(shù)十億美元收購 ，團(tuán)隊(duì)只有12個(gè)人。
這是一個(gè)簡單的問題，您解決的是什么問題？是規(guī)模問題嗎？
當(dāng)你準(zhǔn)備將系統(tǒng)做成復(fù)雜的微服務(wù)架構(gòu)時(shí)，你就要面對(duì)下面眾多的問題：
這是，需要了解和調(diào)整的配置和功能就是無窮無盡的，這樣，我們?cè)诮鉀Q業(yè)務(wù)問題的同時(shí)，又增加許多本來不必要的問題，甚至這些不必要的問題超過了原本的業(yè)務(wù)問題。
事實(shí)上，大多數(shù)公司永遠(yuǎn)不會(huì)達(dá)到真正需要構(gòu)建真正分布式系統(tǒng)的規(guī)模，這實(shí)際上可能只是在浪費(fèi)金錢和時(shí)間。
比分布式系統(tǒng)更糟糕的是錯(cuò)誤的分布式系統(tǒng)。
將問題分解為更小的部分，然后逐個(gè)解決，是一種常見方法。那么，是不是你將一個(gè)服務(wù)分解為多個(gè)服務(wù)，一切都會(huì)變得更容易呢？
這個(gè)說法是充滿理想主義的，每個(gè)微服務(wù)都由一個(gè)專門的團(tuán)隊(duì)維護(hù)，圍繞著一個(gè)漂亮的、向后兼容的、有版本的API。從此之后，你就很少甚至不必與這個(gè)團(tuán)隊(duì)溝通了， 就好像這個(gè)微服務(wù)是由一個(gè)第三方供應(yīng)商維護(hù)的一樣。
但事實(shí)往往是事與愿違的。事實(shí)上，公司各種群聊中充斥著來自團(tuán)隊(duì)的消息，這些消息涉及發(fā)布、錯(cuò)誤、配置更新、破壞性更改等等。每個(gè)人都需要隨時(shí)了解所有的內(nèi)容，甚至比之前更多的內(nèi)容。
構(gòu)建微服務(wù)有很多陷阱，要么完全沒有得到充分認(rèn)識(shí)，要么被簡單地忽視了。
很有可能是，團(tuán)隊(duì)花費(fèi)很長時(shí)間編寫高度定制的工具，并且得到了跟核心產(chǎn)品毫不相關(guān)的教訓(xùn)。這里只是一些經(jīng)常被忽視的方面：
每個(gè)服務(wù)往往都充滿了冗余的樣板文件，樣板代碼。很多時(shí)候，這種樣板的開銷很大，而為了保持微服務(wù)的“微小”，這些冗余、通用的部分會(huì)被抽離出去，那么，這些抽離出去代碼怎么維護(hù)呢？
弄一個(gè)通用庫嗎？如何更新通用庫呢？還是到處保留不同的版本？又或者定期強(qiáng)制更新呢？還是允許每一個(gè)微服務(wù)有重復(fù)呢？
到最后就變成了，去你的，還是按照自己習(xí)慣的方式重新發(fā)明輪子吧。
在單體架構(gòu)中，更新和打補(bǔ)丁很容易，因?yàn)橐磺卸荚谝黄稹Ｔ谖⒎?wù)中，打個(gè)補(bǔ)丁可能意味著在整個(gè)復(fù)雜系統(tǒng)中蜂群一般的更改。如果有十個(gè)微服務(wù)依賴于同一項(xiàng)更改，怎么確定是哪十個(gè)微服務(wù)依賴了更改？如果不知道，那么這些更改如何處理？或者更糟糕的是，如果一個(gè)團(tuán)隊(duì)拒絕進(jìn)行更改怎么辦？那可能會(huì)在重新啟動(dòng)微服務(wù)時(shí)發(fā)現(xiàn)一個(gè)甚至多個(gè)詭異的問題。
最近，有不少的企業(yè)，還是比較大的企業(yè)將一些原本是微服務(wù)架構(gòu)的系統(tǒng)回歸到了單體架構(gòu)。
亞馬遜的 Prime Video 團(tuán)隊(duì)將微服務(wù)架構(gòu)遷移到了單體，云成本降低了 90%。
圖片
在Uber，正在將許多微服務(wù)遷移到所謂的 "寬松服務(wù)"（well-sized services）。確實(shí)，測試和維護(hù)數(shù)千個(gè)微服務(wù)不僅很困難，而且長期來看可能會(huì)比解決短期問題帶來更多麻煩。
圖片
打個(gè)比喻，要從北京到上海，是建造一艘復(fù)雜的宇宙飛船呢，還是買一張高鐵票來的實(shí)在？
英文原文地址：https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html
本文鏈接：http://m.www897cc.com/showinfo-26-76517-0.html一千個(gè)微服務(wù)之死
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)