.背景說明：
之前分享過一個微服務開發框架， “NET Core微服務開發框架”，前兩天在Github上收到一個Issues，是想我這邊提供下完整的運行文檔和配置文件，因為之前想法是弄清楚這幾個東西的職責之后，對于運行的先后順序，和需要的配置key應該都會有了解，所以README編寫只是介紹了用到了哪些東西，沒有說如何運行，但是既然有人問起，我還是滿足一下，就當成是自己回顧了。
二.回顧下項目結構
項目結構比較簡單：
而上面說的 ".NET Core+Swagger+Consul+Polly+Ocelot+IdentityServer4+Exceptionless+Apollo+SkyWalking" 中有幾個東西還未出現，分別是 Consul，Polly，Exceptionless，Apollo，SkyWalking，這里還是分別介紹下
三.安裝啟動微服務周邊應用
在運行服務之前，你或許可以先安裝或開啟以下幾個服務
咋一看這么多需要安裝啟動的是不是感覺很慌？不用擔心，其實如果先排除身份驗證連數據庫都不用讀，可以只用安裝consul就可以，至于apollo可以先將配置寫在代碼的配置文件中，對于將項目跑起來這點來說apollo不是必須的，日志收集也可以暫緩，性能檢測也一樣，我們可以先將核心的跑起來，再來完善他的周邊，秉著這個思路，我們開始運行
四.開始啟動
開發下我們可以這樣啟動consul服務：
./consul agent -dev -data-dir=/data/consul -node=agent-1 -client=0.0.0.0 -bind=10.34.5.101 -datacenter=demo
啟動之后的效果如圖：
dotnet Demo.MicroServer.UserService.dll --urls="http://*:6891" --ip="本機ip" --port=6891
dotnet Demo.MicroServer.UserService.dll --urls="http://*:6892" --ip="本機ip" --port=6892
dotnet Demo.MicroServer.UserService.dll --urls="http://*:6893" --ip="本機ip" --port=6893
這里演示，分別在6891，6892，6893三個端口啟動用戶的微服務實例，啟動之后，consul就開始工作了，如圖：
而Consul是如何發現服務的，其實得益于我們在服務里面添加的一個擴展:
public static IApplicationBuilder UseConsul(this IApplicationBuilder app, IConfiguration configuration)
{
ConsulClient _client=new ConsulClient(c=>
{
c.Address=new Uri(configuration["Consul.ServerUrl"]);
c.Datacenter="Demo.MicroServer";
});
string ip=configuration["ip"];
int port=int.Parse(configuration["port"]);
int weight=string.IsNullOrEmpty(configuration["weight"]) ? 1 : int.Parse(configuration["weight"]);
_client.Agent.ServiceRegister(new AgentServiceRegistration()
{
ID="UserService-" + Guid.NewGuid(),
Name="Demo.MicroServer.UserService",
Address=ip,
Port=port,
Tags=new string[] { string.IsNullOrEmpty(configuration["tags"]) ? "" : configuration["tags"] }, //標簽
Check=new AgentServiceCheck() //健康檢查
{
Interval=TimeSpan.FromSeconds(10), //每隔多久檢測一次
HTTP=$"http://{ip}:{port}/api/health/check",
Timeout=TimeSpan.FromSeconds(5),
DeregisterCriticalServiceAfter=TimeSpan.FromSeconds(60) //在遇到異常后關閉自身服務通道
}
});
return app;
}
并在StartUp.cs中使用了他：app.UseConsul(Configuration);
其實到這里，項目就已經跑起來了，并且具備初步的負載均衡功能，我們可以通過這三個端口其中任意一個來調用服務都是可以的。凡是都有但是，難道要人為去配置什么場景使用哪個ip和端口的服務嗎，或者說要將我們所有的服務都暴露出去嗎，每個服務都加一套登錄鑒權機制嗎？想想都覺得很可怕，那么怎么解決這個問題呢，答案就是.Net 中常用的APi GateWay之：Ocelot
開始啟動Ocelot層：dotnet Demo.MicroServer.Ocelot.dll網關啟動之后就可以通過網關的ip去訪問任意被注冊過的服務，前提是在網關層中有配置好協議，以下面兩個為例子，一個是swagger，一個是用戶服務
//swagger
{
"DownstreamPathTemplate": "/doc/Demo.MicroServer.UserService/swagger.json",
"DownstreamScheme": "http",
"ServiceName": "Demo.MicroServer.UserService",
"LoadBalancer": "RoundRobin",
"UseServiceDiscovery": true,
"UpstreamPathTemplate": "/doc/Demo.MicroServer.UserService/swagger.json",
"UpstreamHttpMethod": [ "GET", "POST", "DELETE", "PUT" ]
},
//UserService
{
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"UpstreamPathTemplate": "/api/{url}",
"UpstreamHttpMethod": [ "Get", "Post", "DELETE", "PUT" ],
"ServiceName": "Demo.MicroServer.UserService",
"UseServiceDiscovery": true,
"LoadBalancerOptions": {
"Type": "RoundRobin"
},
由于每個服務中都已經配置好了swagger文檔，所以這里只需要指定路由協議，一樣的可以通過網關來訪問swagger這里可以通過網關的ip和端口訪問swagger和userservice服務
截止到這里服務的注冊與發現還有網關的上下游配置基本完成，但是圍繞在網關層的東西有很多，例如緩存，限流，熔斷器，在網關層統一鑒權等等，但是這些不是當前要討論的，這個具體根據后續反饋再看是否要單獨拿出來解釋.
五.Apoll配置
上面介紹了運行啟動流程，根據需求，這里也貼一下apollo總的配置項，而網關層和用戶服務層的配置在appsetting中有配置，代碼中已經都有了，這里著重貼下apollo中的配置
Swagger.ServiceDocNames=Demo.MicroServer.UserService,Demo.MicroServer.ProductService
IdentityService4.Uri=http://localhost:5000
IdentityService4.UseHttps=false
如圖：
MySqlConnections=server=mysql_ip;port=3306;database=demo_microserver;User Id=root;pwd=123456;charset=utf8
Swagger.Name=Demo.MicroServer.UserService
Swagger.Version=v1
Swagger.DocName=Demo.MicroServer.UserService
Swagger.Title=Api interface documentation
Swagger.Description=See below for specific interface
Swagger.Contact.Name=PeyShine
Swagger.Contact.Email=PeyShine@qq.COM
Swagger.XmlFile=Demo.MicroServer.UserService.xml
Exceptionless.ApiKey=LmqMIxSTW0U68pKwJ3xXqrNrLqS6oEociW7OexNt
Exceptionless.ServerUrl=http://exceptionless_ip:5000
Consul.ServerUrl=http://consul_ip:8500
MongoDB.DefaultConnection=mongodb://dev:Aa123456@mongo_ip/demo_db
MongoDB.DefaultDatabase=demo_db
MongoDB.DefaultTable=users
如圖:
六.總結
本文作為文章".NetCore微服務開發框架"的一個補充擴展，主要是介紹如何一步步啟動Demo.MicroServer微服務框架，里面關于網關還有IdentityServer4沒有進行深入討論，想法是只要能先將項目核心部分跑起來，周邊應用可以自行添加，后續再根據反饋是否要更加詳細的去介紹。其實理解了幾個開源項目自己的職責之后，對運行流程就不難理解了，動手試試吧!
晚上好，我的網工朋友。
服務器是一個很廣泛的概念，涵蓋了各種類型和規格的計算機，用于提供各種網絡和數據服務。
而機架服務器是當前數據中心和專業計算環境中，使用最為廣泛的服務器類型之一。
機架式服務器的外形看來不像計算機，而像交換機，在規劃上，有1U（1U=1.75英寸）、2U、4U等規格。
一般情況下，我們經常會講2U服務器、42U服務器，會把機架式服務器安裝在標準的19英寸機柜里面。
這些都是啥？你了解嗎。
今天和你聊聊服務器的各種類型，再詳細解釋解釋，服務器里的1U、2U、4U、42U分別是什么。
今日文章閱讀福利：《 華為機架服務器白皮書 》
給你分享一份華為廠商的某機架服務器白皮書，進一步觀察學習相關硬件部件知識。私信我，發送暗號“機架服務器”，限時獲取。
服務器是一類提供數據處理、存儲和應用服務的計算機。
設計可以多樣化，包括塔式、機架式、刀片式和微型服務器。通常具備強大的處理器、大量內存和大容量存儲設備。
可以執行特定的服務任務，如文件服務、數據庫服務、網絡服務等；也可以作為網絡中的中心節點，處理和管理數據交換。
通常運行特定的服務器操作系統，如Windows Server、Linux等。
一般廣泛應用于商業、教育、政府和科研機構。根據需求，服務器可以配置為專用服務器或多功能服務器。
適用于從小型辦公室到大型企業和互聯網服務提供商的各種環境。
如果按照產品外形來分類的話，主要可以分為這4種：
01 機架式服務器（Rack Server）
這種服務器設計為安裝在標準的19英寸機架內。
機架式服務器的高度通常以“U”為單位，1U等于1.75英寸。
廣泛應用于數據中心和企業級服務器房，特別適合于空間有限且需要高密度計算的環境。
02 塔式服務器（Tower Server）
這種服務器外形類似于傳統的臺式電腦，但通常更大、更強大。
因為可以單獨放置，不需要專門的機架或機柜，適合小型企業或者辦公室環境，特別是對空間沒有特別要求且需要獨立運行的場合。
03 刀片式服務器（Blade Server）
刀片式服務器是一種高度集成的系統，包含多個薄而狹窄的服務器“刀片”，這些刀片插入一個共享的機架內。
每個刀片都是一個獨立的服務器，刀片式服務器能夠提供高密度的計算能力，節省空間和電源。
適用于需要高密度服務器部署、集中管理和節能的大型數據中心。
04 微型服務器（Microserver）
微型服務器是一種體積小、能耗低的服務器，適合處理輕量級的任務，如提供基本的文件共享、數據備份和低強度的計算任務。
這種服務器適合小型企業或者那些不需要大型、高性能服務器的場景。
適合小型企業或者需要處理基本的文件共享、數據備份和低強度計算任務的環境。
這些服務器類型各有其優勢和局限性，選擇時應根據實際的業務需求、預算和技術環境來決定。
例如，數據中心可能更傾向于使用機架式和刀片式服務器，而小型辦公室可能更適合使用塔式或微型服務器。
“U”是unit的縮略語，是一種用于衡量機架服務器和其他機架安裝設備高度的單位。
這個標準單位允許不同制造商生產的設備能夠共同適用于標準機架系統。
規定了服務器的尺寸，可以使服務器以一定的尺寸放在機架上。
在機架中，每個1U的高度代表了設備能夠占用的最小垂直空間。例如：
機架上有固定服務器的螺孔，以便它能與服務器的螺孔對上號，再用螺絲加以固定好。
這種標準化設計使得各種不同高度的設備可以高效、緊湊地安裝在同一個機架內，從而最大化數據中心的空間利用率。
剛剛我們已知U的概念，作為機架式服務器的標準尺寸單位，1U等于1.75英寸（約4.445厘米），這個高度是基于標準19英寸機架的規格。
機架的總高度以U為單位計量，確定服務器機架可以容納的服務器數量。
在機架式服務器尺寸當中，常見的就是1U服務器、2U服務器、4U服務器。
這些服務器的尺寸是：
1U=4.445厘米
2U=4.445*2=8.89厘米
4U=4.445*4=17.78 厘米
接下來給你具體拓展一下這幾種類型的功能和特點。
01 1U服務器
1U服務器的高度為1.75英寸。這是最小的機架服務器尺寸，節省空間，適合密集配置。
通常用于輕到中等負載的計算任務。在功能上可能受到物理空間的限制，比如CPU數量、內存槽數量和存儲容量。
02 2U服務器
2U服務器的高度為3.5英寸（2 x 1.75英寸）。
可以提供更多的擴展性，支持更多的內存、存儲和更多/更大的冷卻系統。適用于需要更高計算能力和額外硬件組件的場景。
03 4U服務器
4U服務器的高度為7英寸（4 x 1.75英寸）。
這些服務器提供了最大的擴展空間，可以容納大量硬件，如多個CPU、大量內存和多個存儲設備。
也可以用于非標準的用途，如加入GPU卡用于高性能計算或視頻渲染。
04 1U、2U服務器最熱門
選擇服務器時，除了考慮性能需求，還需要考慮空間和成本效益，這是因為數據中心通常按照機柜占用空間來計費。
所以在實際使用當中，1U或者2U服務器是最經常使用的。
1U服務器因其超薄的設計而節省空間，非常適合輕度至中度的計算任務。
2U服務器提供了更好的擴展性和冷卻能力，適合于更高的存儲需求和性能。
05 有3U服務器嗎？
這時候，你可能會問了，為什么沒有3U服務器？
實際上，3U服務器是存在的，而且在某些特定的應用中可能更有用，比如需要額外的硬件擴展或特殊配置。
但因為它們的尺寸增加會導致每臺服務器占用更多的機架空間，所以在標準化和空間優化的大環境中，它們沒有1U和2U服務器那么受歡迎。
而且，很多能用3U服務器完成的任務，通過使用更加流行的4U服務器也能夠實現。
后者提供了更大的空間以支持更多的硬件和更高的性能配置，那為啥不用4U？是這個理吧。
19英寸機柜的名稱來源于機柜內部前后兩排垂直的安裝柱之間的寬度，標準為19英寸（約為48.26厘米）。
這種尺寸是行業標準，意味著多數機架式服務器、網絡設備、數據存儲設備和其他電子設備都設計為可以安裝進這種寬度的機柜。
19英寸是指機架式設備兩個掛耳之間的距離。這是目前大部分機架式設備的結構標準。
01 核心組成部分
標準機柜以其結構的簡潔性和實用性為特點，主要由下面這幾個核心組成部分構成：
基本框架：構成機柜的外部結構和支撐骨架，提供穩定性和保護作用。
內部支撐系統：包括固定設備的軌道和支架，以及可調節的擱板，用于安裝各種標準和非標準設備。
布線系統：設計以方便電源線和數據線的安排，通常包括電纜通道和集線器，以保持內部有序。
通風系統：包括通風孔、風扇或者集成的冷卻系統，確保機柜內部設備的散熱和良好的空氣流通。
02 深度、寬度、高度有多種規格
盡管19英寸是最常見的寬度，機柜的深度和高度、寬度卻有多種規格。
寬度方面，雖然19英寸面板設備的安裝寬度標準為465.1mm，但機柜本身的物理寬度一般有600mm和800mm兩種規格。
高度上，機柜的范圍可以從0.7m到2.4m不等，而市面上常見的成品機柜高度一般是1.6m或者2m。
深度則從450mm到1000mm不一，這取決于要安裝的設備尺寸，同時也有廠商提供定制深度的服務。
常見的成品機柜深度包括450mm、600mm、800mm、900mm和1000mm。
大多數19英寸標準機柜的設備面板都是依據nU的高度規格來設計制造的。
對于那些非標準尺寸的設備，通過安裝附加的適配板也能夠安裝在19英寸機柜中并進行固定。
42U機柜是一種標準的機架式服務器機柜，總高度大約為73.5英寸（約186.69厘米）。
這種機柜被廣泛應用于數據中心和大型IT設施中，因為它能夠提供足夠的空間來安裝多臺服務器、網絡設備、存儲設備以及其他機架式電子設備。
42U機柜的一般分類看下面這張圖就一目了然了。
一個機柜所放的服務器是有限的，42U高度的機柜并不代表著實際能夠放42個1U服務器。
42U機柜可以提供足夠的垂直空間來安裝大量的機架設備，比如說服務器、交換機、路由器、UPS系統和其他電子硬件。
而且可以支持多種配置，包括固定架、可調架和滑動抽屜等，為不同設備的安裝和維護提供便利。當然，散熱和挪動的空間也得預留出來。
原創：老楊丨10年資深網絡工程師，更多網工提升干貨，請關注公眾號：網絡工程師俱樂部