前言node
美圖公司是如何使用阿里雲的python
咱們是如何作成本優化的mysql
咱們在阿里雲上遇到了哪些坑web
咱們如何作自動化運維的redis
前言
本篇文章可能更多的是文字表述，沒啥高深的用詞，都是大白話，須要各位朋友有耐性的閱讀下去，也但願各位朋友可以提出寶貴建議。sql
美圖公司是如何使用阿里雲的
關於使用方面，我想從如下幾個點簡單敘述一下，shell
-
權限規劃 -
區域規劃 -
網絡規劃 -
型號規劃 -
統一登陸規劃 -
命名規劃
權限規劃
權限規劃只要是在帳號權限規劃上，通常是主帳號+子帳號，而後經過ram來進行對應受權，爲何要作這個，由於主帳號通常控制在運維手上，子帳號可能會存在其餘運維手上以及某些開發手上，那麼就須要作嚴格的權限控制。目前阿里雲ram有幾個點：用戶，羣組，角色，策略等功能，目前角色和策略都支持自定義，而後能夠應用到用戶上，羣組上。角色能夠附加到ecs上，能夠用高權限獲取一些雲上資源信息。後端
區域規劃
作區域規劃須要考慮幾點：安全
-
第1、你的業務架構，好比我有idc機房在北京，那麼咱們上雲的話通常會考慮北京region，又好比個人業務用戶主要分佈在江浙一帶，那麼咱們通常就考慮上海或者杭州region。 -
第2、必定要找阿里雲技術問到當前region的最新可用區是哪一個，機器儲備量級是多少，由於新可用區通常會有新機器，新型號，通常來講帶來的好處就是性能高還便宜；另外老可用區機器型號很是少，常常會遇到售馨的問題。 -
第3、當咱們定好了區域以後，後續再改變會很是麻煩，因此前期的調研準備必定要完善，考慮要全面。
網絡規劃
關於網絡規劃，主要有如下幾點須要考慮下：微信
-
第1、vpc規劃，能夠按照你的業務架構劃分vpc，不一樣vpc之間能夠作一些安全組也隔離流量。例如我有大數據業務，普通業務，運維業務，那麼我能夠簡單建立幾個vpc：大數據vpc，生產業務vpc，測試業務vpc，運維vpc。 -
第2、子網劃分，每個vpc劃分多個子網，好比我拿生產業務vpc來舉例子，能夠劃分爲：容器子網，mysql子網，redis子網等。(注意：子網在阿里雲就是交換機的概念) -
第3、子網的ip數量，這個的定義須要提早規劃和統計業務量級，vpc自己是一個大的網段，單個子網的網段要合適，太大浪費，過小擴展麻煩。
咱們內部的子網劃分：
型號規劃和命名規劃
把這兩個放一塊兒講，通常來講公司會選擇一款型號來做爲本身的主力機型，這個配置比較貼近本身的業務形態，另外這個機型也要跟阿里雲備案，讓他們提供足夠大的節點池。命名規劃的話，咱們能夠按照業務提供能力來作不一樣的命名方式：
k8s節點: aly-k8snode-10-10-10-1.meitu.commysql: aly-mysql-A-10-10-10-2.meitu.comredis: aly-redis-B-10-10-10-3.meitu.com
作好這個，第一能更好區分不一樣節點功能，第二能更好的去作自動化運維工做。
統一登陸規劃
作統一登陸就是要作跳板機、作權限管理。有如下幾點要考慮：
-
第1、用戶登陸虛機需求，運維側須要作一個公共跳板機，全部的登陸操做都須要經過該機器跳轉。 -
第2、開發用戶對於線上的機器不能有永久權限，開放的通常是臨時權限，因此咱們須要有一套受權，回收權限的平臺。 -
第3、作好操做追蹤，防止一些 高危人員作一些非法操做。
咱們內部的工單平臺：
咱們是如何作成本優化的
關於成本優化，是一個很是重要而且也很是頭疼的一件事情，當服務趨於穩定後，必定要慢慢去優化成本。那麼關於成本優化的事項，咱們作了這些事情：
-
容器化 -
彈性伸縮的深刻使用 -
作好資源開通記錄和監控 -
架構規劃(內網和公網) -
增長混布實例 -
定時巡檢，刪除無用資源 -
最低實例實行包年包月
容器化
容器化趨勢，他也是做爲成本優化最好的方案之一，目前咱們公司95%的業務已經容器化。咱們在雲上使用的是託管的k8s集羣，另外咱們本身有一套自研的k8s管理工具，來作平常的業務發佈，迭代等操做。
彈性伸縮的深刻應用
我認爲雲服務和自建IDC最大的差距就是彈性伸縮的應用，我我的也是很是喜歡彈性伸縮這一個服務，由於他能很好的提高資源利用率，而且顯著的下降成本。咱們在如下幾個場景用了彈性伸縮服務：
-
第1、託管k8s服務的容器節點。 -
第2、普通虛機業務開通彈性伸縮。 -
第3、容器業務服務開通HPA。 -
第4、共享帶寬的彈性。
結合這些彈性伸縮的場景，咱們作了一些工具，主要是觀察全局的一個狀況。阿里雲彈性伸縮控制檯總覽：
容器單個業務伸縮策略詳情：
作好資源開通記錄和監控
這個很是重要，由於咱們常常會遇到一個狀況是：業務臨時有個需求，須要開一臺測試機器來作業務驗證，咱們開通完交付。他們測試完成以後並不會通知你是否需還須要這臺機器，致使慢慢被遺忘，因此增長了額外的費用。另一點咱們也能夠根據記錄去作一些下線工做：當一個業務須要下線時候，咱們能夠根據他們的資源申請單去下線相關的服務，避免漏下或者錯下。
架構規劃(內網和公網)
這個點涉及到的通常就是流量費用，公網帶寬費用，咱們遇到過一些狀況是：業務調用能走內網的他不走內網，非要走公網，甚至他根本就不知道有內網地址。因此基於這個咱們作了如下幾點：
-
第1、服務上線評審，新服務上線必定要拉上運維，開發一塊兒作一個評審，由於開發不懂線上網絡結構，他們認爲只要服務可以正常通就是沒問題的，因此他們忽略了很是多的細節，好比內網調用等。 -
第2、服務提供內網域名，公司業務越多，那麼存在互相依賴的地方就越多，這些內部依賴的動做能經過內網的必定要經過內網，不要從公網繞一圈。好比我在阿里雲上下載oss圖片，明顯有內部的oss地址可用。 -
第3、服務部署規劃，當有A的子服務B須要上線，且B是徹底給A調用的，那麼該服務上線的區域必定是A所在區域，不要存在跨可用區，跨region，跨專線等操做，這些都會帶來額外的流量費用。
增長混布實例
混布通常是針對非容器化業務的，雖然混布不建議，可是也是不能缺乏的。公司確定會有相似的業務，而且年代久遠，無人維護，像這類業務就能夠統一丟到一兩臺機器上部署便可。
定時巡檢，刪除無用資源
這一步也是運維平常，咱們會跑一些自動化的腳本去刪除一些無用的服務，而且列出一些無主資源去讓業務方確認是否釋放。
-
鏡像。阿里雲的鏡像能夠只留最新的幾個，刪除老的鏡像。 -
快照。跟鏡像相似。 -
磁盤。刪除無掛載，也無需保留的磁盤。 -
OSS。清理oss空間，業務方會保留很是多的靜態資源，他們也不會刪除，也不會去管，因此須要咱們來推進他們來確認清理。 -
ECS。刪除臨時測試機器，刪除業務已經下線的機器。 -
......
雖然這些都是比較便宜，不過聚沙成塔，成本優化自己就是一個漫長的過程，因此一點點的優化纔是王道。
最低實例實行包年包月
這個方案主要是針對彈性伸縮來講的，咱們會觀察每個彈性伸縮組一天的監控數據，包括cpu利用率，實例數量。而後觀察幾周的數據，發現最低的一個實例數量，把這部分實例轉成包年包月。
以下圖，咱們能夠拿2-3臺進行轉包月操做：
咱們在阿里雲上遇到了哪些坑
其實阿里雲在國內市場已經作的很是好了，遇到的坑也大多比較貼近自身業務，有些坑他們也已經作了架構調整規避了。
-
區域資源配額問題 -
NAT 帶寬問題 -
實例售馨問題 -
可用區交換機網段過大
其實坑還有不少，只不過有些都是小坑，有些可能我本身也有點忘記了。
下面簡單解釋下這些坑：
區域資源配額問題
咱們在重要節日推廣，須要大量的機器儲備，某年春節的時候遇到了區域資源配額瓶頸問題，即這個帳號默承認以使用多少的vcpu(這個主要是按需的，包年包月的不會計算進來)。當時推廣的時候，咱們機器徹底擴不上來了，最終排查到是資源配額上限了，也是緊急通知阿里雲幫忙調整。
NAT 帶寬問題
最先阿里雲的 NAT 仍是有單獨的帶寬配置的，當時咱們有一個服務推廣效果比較好，直接把 NAT 打滿了，致使咱們整個vpc內的網絡都很是慢，嚴重影響了咱們服務質量。目前阿里雲剛把 NAT 帶寬調整成共享帶寬包，帶寬和 NAT 實現了分離，另外帶寬也能夠動態調整，很是的方便。
實例售馨問題
如前面所說的，一個企業通常會選用一個主力型號，當時是彈性的機器過多，致使該型號實例售馨，新機器沒法建立。針對這個問題，咱們作了以下兩個解決方式：
-
設置多實例彈性，彈性伸縮能夠配置彈多個實例型號，而且也有優先級。 -
替換大規格機器，簡單來講就是用一臺大規格實例頂替多臺小規格實例。
可用區交換機網段過大
遇到這個坑的背景也是咱們想使用新可用區，由於咱們IDC跟阿里雲是默認專線打通的，因此會存在網段分配的問題，當初分配給阿里雲的網段已經用完了，因此我想開新區，必須釋放老的交換機或者拆分它。分配的網段用完了的根本緣由仍是：當初規劃不合理，交換機設置過大，而後根本用不到這麼多。
咱們如何作自動化運維的
-
彈性伸縮服務更新 -
統一登陸權限申請 -
雲上資源數據統計 -
自定義資源監控告警 -
定時彈性伸縮控制成本 -
重要業務推廣通知 -
移動端運維
關於自動化運維這一塊，其實須要緊密貼近公司的業務來作。只要你平時感受哪一個操做常常作，又很是繁瑣，那麼他就能夠用工具替代，因此下面的東西都是我平時常常操做而抽象出來的。
彈性伸縮服務更新
彈性伸縮服務，一個很是重要的操做就是更新，咱們每一個彈性伸縮組都有上百個實例，不可能去一個一個更新，確定是建立一個鏡像後，而後按照這個鏡像進行滾動更新。咱們有100個左右的彈性伸縮組，因此這個更新操做是常常須要的，因此我作了自動更新操做，並集成到了移動端和web端。
統一登陸權限申請
咱們有本身的一套權限申請平臺，相應的人員能夠申請線上的機器，申請能夠是臨時的，也能夠是擁有的。
雲上資源數據統計
這個統計信息會統計咱們當前阿里雲使用了多少機器，多少cpu，多少內存。這個信息會發給咱們老大，同時開發老大也會關注這個，由於涉及到成本。
自定義資源監控告警
其實阿里雲集成的監控告警已經比較全面了，他能夠經過郵件、短信、釘釘等方式發送出來。不過涉及到業務層面的，或者更貼合咱們本身需求的，通常都會自定義通知，你們能夠看我這篇chat，《美圖分享：適用於中小型企業自研的監控告警通知系統（附源碼）》，我平時自定義告警都是經過這個項目進行發送的，種類繁多。
定時彈性伸縮控制成本
咱們徹底按照阿里雲彈性伸縮設置默認的伸縮規則有時候可能還不能知足，藉此咱們可能還會設置一些定時伸縮，好比我晚上2點就讓它維持兩臺機器。這個也是控制服務穩定性的一個操做，由於在某些時刻，服務是1臺機器扛不住，兩臺機器會縮容的狀態。咱們開發了一個工具展現定時任務的列表(因爲業務遷移了，因此這裏沒數據了，嘿嘿)
重要業務推廣通知
通常咱們的業務在重要節日中，都會有推廣。那麼推廣前，咱們必定須要保障該服務的穩定性，該擴容的擴容，該加配置的加配置，因此咱們作了重要推廣通知的平臺，來重點保障春節，五一，國慶等重要節日業務推廣。
移動端運維
移動端運維也是今年咱們新引入的，由於咱們已經厭煩了每天揹着電腦了，能在手機上操做就在手機上操做了。其實上面的不少服務都是移動端的界面。因爲本身開發能力有限，因此只開發了 IOS 客戶端，後端就是python寫的。(有興趣的朋友，能夠一塊兒交流一下！)
本文分享自微信公衆號 - 程序猿的野生香蕉（gh_2e510bc5c532）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。