Горната снимка е сивото издание на Tencent, обикновените потребители могат да го достъпят, Alibaba Cloud сървърът не може да бъде достъпен, пингът е нормален, а резолюцията на IP също е нормална
Просто е недостъпно, вижда се, че Tencent също обича да си играе с сиви тонове на издание...
1. Защо издание в сиви тонове
- Интернет услугите се сменят често, а цикълът на пускане е кратък. Скоростта и качеството винаги са трудни за комбиниране.
- Сивото публикуване може да намали риска от публикуване и да намали обхвата на въздействието.
- Намалете зависимостта от тестване и намалете разходите за изграждане на данни за офлайн самотестване.
- Удобно е централно да се следят логовете и да се публикуват изцяло. Поради ролята на балансирането на натоварването във всеки слой е трудно да се проследи пълна връзка за обаждане.
- Можете да използвате тестови акаунти в сиви тонове, а след това реални потребителски акаунти в сиви тонове, след като тестовият акаунт премине, за да намалите още повече риска и въздействието от публикуването.
- Лесно връщане назад.
Проблеми, които не могат да бъдат решени с издания в сиви тонове
Трябва да се подчертае, че "поносимото въздействие", споменато по-горе, трябва да бъде възстановимо, например API не може да бъде извикан за определен период от време, но след ремонт може да бъде успешно извикан. Постоянната загуба или унищожаване на потребителски данни (като информация за продукти, информация за поръчки и др.) е нетърпима. Затова е отговорност на архитектите на интернет предприятията да възстановят изгубените потребителски данни до скорошно състояние (например преди час или седмица) чрез ръчна намеса в случай на загуба на потребителски данни поради проблеми в производствената система (като редовно архивиране на потребителски данни, писане на оперативни логове и др.).
СЪВЕТИ Първо тествайте сивата политика на акаунта си, за да намалите риска от повреда или загуба на реални потребителски данни.
2. Какъв ефект се очаква?
Независимо от промяната, искаме конкретни заявки да бъдат насочени към нашата версия на промяната (версия в сиви тонове) за наблюдение и валидация.
3. Стратегия в сивите тонове
Всъщност, това е въпросът, който заявките трябва да се насочват към нашата версия в сиви тонове (машина за сиви тонове). Това често е силно свързано с бизнеса. Например, за API обикновено има следните изисквания:
Конкретни потребители (например тестови акаунти)
Конкретни приложения (например тестови приложения или партньорски приложения)
Специфични модули и интерфейси (само някои интерфейси изискват grayscale, което обикновено е модификация на API контейнери, а някои API-та, които не са много важни, се използват за тестване в сиви тонове). ）
Конкретна машина (някои IP адреси на заявка се препращат към машината с сиви тонове)
4. Обсъждане на схеми в сивите тонове
Решение 1: Нивото на кода се оценява по договорения флаг, а старото и новото се превключват динамично – подходът на Amazon
Реализация:
Скрий превключвателя в кода, направи if-else преценка и настрой превключвателя на включено за машини, които изискват сиви тонове, иначе е изключен. Има две версии за всяко издание.
заслуга
Бързо връщане назад, няма нужда да препубликуваш и рестартираш системата.
Недостатък
Бъдете склонни към програмиране.
Разклонената логика носи сложност.
Този метод беше използван от автора, когато бях в Alibaba, като превключвах базата данни с продукти от Oracle към MySQL и използвах променлива на състоянието за контрол. Така се постига ефектът на плавна миграция.
Опция 2: Машина за предварително пускане – практиката на Alibaba
Всъщност, това не е сиви в истинския смисъл. Защото тази предварителна машина е вътрешен IP и няма външна услуга. За проверка е необходимо обвързване на домейна. Но данните са изцяло онлайн. Така че това е по същество прост подход за някои конкретни потребители на Grayscale (потребители, които имат достъп до машината в сивите тонове, вътрешни тестови потребители). Всъщност има подобен подход и от страна на API, която е нашата Gamma среда, а също така предоставяме домейна на Gamma машината, за да улесним външните кооперативни потребители да си сътрудничат при тестването.
заслуга
Просто
Недостатък
Waste a machine (това може да се постави в производствената среда след приключване на предварителното пускане и да бъде премахната от nginx по време на предварителното пускане, но е необходима поддръжка на O&M.) ）
Не е достатъчно гъвкав
IDL услугите могат да се използват само за машини от слоя достъп, а IDL услугите трябва да се разглеждат отделно.
Опция 3: Разгръщане на SET
1. Разполагане в изолация според службите
Например, в настоящата практика на API контейнери, детайлността на внедряването може да се достигне до ниво на API, а фронтендът да се превърне според nginx. Като какво:
Контейнер за микро пазаруване: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API контейнер: api.yixun.com
API за онлайн пазаруване Container:api.buy.qq.com
Горното е изолирано внедряване на ниво голям бизнес. Може също да бъде допълнително усъвършенстван до ниво модул, като например API на виртуалната услуга e-commerce, който е под-бизнес модул, задържан под Paipai, но тъй като са свързани с WeChat, броят на посещенията се е увеличил значително, за да се избегне засягане на другите бизнеси на Paipai, и за да се избегне влиянието от други бизнеси, API тук е да разположи две машини отделно за тях, nginx може да бъде конфигуриран да източва достъпа до виртуалния API:
Виртуален API контейнер: http://api.paipai.com/v2/virbiz
По този начин, когато пуснем версия, първо можем да изберем Yixun с най-малък бизнес обем за публикуване и след това да отбележим, че няма проблем, преди да използваме всички други платформи.
2. Внедряване чрез потребителска изолация
Това не е много подходящо за отворени платформи, но е много подходящо за приложения като SNS. Например, QQ системата е разделена на няколко набора според сегментите с потребителски номер, като всеки набор съдържа 100 милиона последователни числа. Ако приемем, че последният QQ брой е близо до 1 милиард, има общо 10 комплекта (от 1 до 10). По този начин можете да изберете един от SET-овете за публикуване всеки път, а високопоставените QQ често не са много важен потребител, затова SET10 ще бъде пуснат първи.
заслуга
Изолирано внедряване с минимално въздействие между бизнес линиите. Автоматично поддържа публикуване в сиви тонове.
Недостатък
Грануларността на сивите скали зависи от грануларността на изолираното разполагане, което обикновено е голямо.
Загуба на машини в сравнение с централизирано внедряване.
Версиите на всяка бизнес линия може да са непоследователни, което не е благоприятно за унифицирано управление.
Има определени разходи за внедряване и внедряване
Схема 4: Динамично маршрутизиране
Метод: Използвайте политика за сиви тонове, която може гъвкаво да се конфигурира така, че да влияе на поведението на баланса на натоварването и да му позволи да върне IP адреса и порта на услугата в сивите тонове според политиката за сиви тонове.
Подходящо за сервизни сиви тонове с задния офис IDL.
заслуга
Гъвкав, контролируем.
Недостатък
Настоящият конфигурационен център и самият L5 не вземат предвид определени политики за маршрутизиране и не са мащабируеми, затова трябва да се разработват извън тях.
Източниците на метаданни на API са сравнително разпръснати и в момента метаданните на API и IDL, нивата на API и честотите са разпределени между различни източници на данни, като сега е необходимо да се добави източник на данни за маршрутизиране в сиви тонове.
Обикновено има три начина за публикуване на grayscale nginx+lua, nginx се разпределя според бисквитките, а nginx се присвоява според теглото:
nginx+lua се различава според IP адреса на посетителя, тъй като компанията експортира IP адрес и уебсайтът ще бъде достъпен или в старата, или в новата версия, което не е подходящо за този метод
nginx присвоява тегла въз основа на тегла, което е лесно за реализиране и може да се пробва
nginx се разделя според бисквитките, а grayscale публикува според потребителите
|
Публикувано в 9.03.2017 г. 15:48:27 ч.
|
|
|
|
