regal 是乙個用於"灰度發布"或 a/b testing的智慧型分組引擎
主要功能:
舉個最簡單的例子，比如需要針對乙個版本進行灰度發布，而這一版本對應的可能是一大堆伺服器集群， 如下圖:
就像圖中描述的一樣，無論你的伺服器是多還是少，尤其很多中小型企業在進行灰度發布時，通常會遇到所制定的分流策略在實際的技術或開發中如何去實現，是機器直接寫死？
因此讓regal智慧型分組引擎直接介入，讓它來根據你的策略提前進行動態地分組分流。
在這裡，我再舉乙個簡單的例子，方便大家能夠更清楚的明白regal的主要工作：
假設有乙個版本a，需要針對六臺機器進行發布
現在應該已經了解regal到底是什麼乾貨了吧，當然了，上面的例子是伺服器非常少的情況，實際情況中，所面對的伺服器集群是非常多，這個時候可以通過提供的combine和schedule兩個api進行策略調整。詳情可以見下文的使用介紹
in [1]: from regal import baseinfo
# 初始化資訊，請注意一下格式
in [6]: ab = baseinfo(
combine=2 # combine 希望以每組多少臺伺服器作為一組,進行使用者群b的分流
# 在這個例子中為2臺
# 預設：每組1臺
)# grouping() 進行分組
in [11]: smart_grouping = ab.grouping()
# result屬性 進行分組後的返回結果
in [12]: smart_grouping.result
out[12]:
[['10.1.1.1'], ['10.1.1.2', '10.1.1.3'], ['10.1.1.4', '10.1.1.1.5']])]
versiona:
（第一組） groupa ip...... 使用者群a
（第二組） groupb1 ip...... __
（第三組） groupb2 ip...... |
（第四組） groupb3 ip...... | -- 使用者群b
...... --|
你可以把每一組直接放在ansible、saltstack、pssh或非同步io框架等等進行發布；
甚至你也可以和前端nginx＋lua進行組合；
每組進行發布，一旦出現異常，你可以利用發布元件，或者你自己寫一套異常抓取工具來停止發布，這個時候就不會再針對剩下的組進行發布操作了。
把回滾也看作一種發布,就不多說了
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布入門
我們的產品是個比較典型的網際網路產品，產品公升級採用 小步快跑 的方式，一般採用保持每週或每兩周一次的發布頻率，同時，每週會有數次bug上線。系統上線總是伴隨著風險，系統重大bug的風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險等等，因為這些風險的存在，很多次上線都是通宵達旦...