Вищенаведене зображення — це реліз Tencent у відтінках сірого, звичайні користувачі можуть отримати до нього доступ, доступ до сервера Alibaba Cloud недоступний, пінг нормальний, а IP роздільної здатності також нормальний
Вона просто недоступна, видно, що Tencent також любить гратися з відтінками сірого релізу...
1. Чому вихід у відтінках сірого
- Інтернет-сервіси часто змінюються, а цикли випуску короткі. Швидкість і якість завжди важко поєднати.
- Сірі видання можуть знизити ризики публікації та зменшити масштаб впливу.
- Зменшити залежність від тестування та знизити вартість створення даних для офлайн-самотестування.
- Зручно централізовано моніторити журнали та публікувати їх повністю. Через роль балансування навантаження на кожному рівні важко відстежити повне зв'язок виклику.
- Ви можете використовувати тестові облікові записи Grayscale, а потім у відтінках сірого реального користувача після завершення тестового акаунта, щоб ще більше знизити ризики та вплив публікації.
- Легкий відкат.
Проблеми, які не можна вирішити за допомогою релізів у відтінках сірого
Слід підкреслити, що згаданий вище «терпимий вплив» має бути відновлюваним, наприклад, API не можна викликати певний час, але після ремонту його можна успішно викликати. Постійна втрата або знищення даних користувачів (таких як інформація про продукт, замовлення тощо) є неприйнятною. Тому відповідальність архітекторів інтернет-підприємств — відновити втрачені дані користувачів до недавнього стану (наприклад, годину або тиждень тому) шляхом ручного втручання у разі втрати даних користувачів через порушення виробничої системи (наприклад, регулярне резервне копіювання даних користувачів, ведення журналів операцій тощо).
ПОРАДИ Спочатку перевірте політику білого відтінку вашого акаунта, щоб зменшити ризик пошкодження або втрати даних реальних користувачів.
2. Який ефект очікується?
Незалежно від зміни, ми хочемо, щоб конкретні запити були спрямовані до нашої версії зміни (версія у відтінках сірого) для спостереження та валідації.
3. Стратегія відтінків сірого
Насправді, саме запити мають направлятися до нашої версії у відтінках сірого (машина з відтінками сірого). Це часто тісно пов'язано з бізнесом. Наприклад, для API зазвичай існують такі вимоги:
Конкретні користувачі (наприклад, тестові акаунти)
Конкретні додатки (наприклад, тестові додатки або партнерські додатки)
Конкретні модулі та інтерфейси (лише деякі інтерфейси потребують відтінків сірого, що зазвичай є модифікацією контейнерів API, а деякі API, які не є дуже важливими, використовуються для тестування відтінків сірого.) ）
Конкретна машина (деякі IP-адреси запитів перенаправляються на машину з відтінками сірого)
4. Обговорення схем у відтінках сірого
Рішення 1: Рівень коду оцінюється за погодженим прапорцем, а старий і новий динамічно перемикаються — підхід Amazon
Реалізація:
Закопайте цей перемикач у коді, зробіть рішення «if-else» і встановіть перемикач у режим «увімкнено» для машин, які потребують відтінків сірого, інакше він вимкнений. Для кожного релізу є дві версії.
Заслуга
Швидкий відкат, немає потреби перепублікувати і перезавантажувати систему.
Недолік
Будьте схильні до програмування.
Розгалуженість логіки приносить складність.
Цей метод використовував автор, коли я працював в Alibaba, переключаючи базу даних товарів з Oracle на MySQL і використавши змінну стану для керування. Таким же досягається ефект плавної міграції.
Варіант 2: Передрелізна машина — практика Alibaba
Насправді, це не відтінки сірого в справжньому розумінні. Тому що ця машина до релізу є внутрішньою IP і не має зовнішнього сервісу. Для верифікації потрібне зв'язування домену. Але дані повністю онлайн. Отже, це, по суті, простий підхід для деяких конкретних користувачів Grayscale (користувачів, які мають доступ до машини з відтінками сірого, внутрішнього тестування). Насправді, схожий підхід існує і на стороні API — нашому середовищі Gamma, а також ми надаємо доменне ім'я машини Gamma, щоб зовнішні кооперативні користувачі могли співпрацювати з тестуванням.
Заслуга
Просто
Недолік
Відходити машину (це можна перемістити у виробниче середовище після завершення попереднього релізу і видалити з nginx під час передрелізу, але підтримка O&M потрібна). ）
Недостатньо гнучкий
Сервіси IDL можуть використовуватися лише для машин рівня доступу, і IDL-сервіси слід розглядати окремо.
Варіант 3: Розгортання SET
1. Розгортатися ізольовано відповідно до служб
Наприклад, у сучасній практиці API контейнерів деталізація розгортання може бути досягнута до рівня API, а фронтенд — відповідно до nginx. Наприклад, що саме:
Контейнер API для мікрошопінгу: api.weigou.qq.com
Pat API Container:api.paipai.com
Контейнер API Yixun: api.yixun.com
API онлайн-шопінгу Container:api.buy.qq.com
Вищезазначене — це ізольоване впровадження на рівні великого бізнесу. Його також можна вдосконалити до рівня модуля, наприклад, API віртуальної сервісної електронної комерції, який є суббізнес-модулем, що висить під контролем Paipai, але оскільки вони підключені до WeChat, кількість відвідувань значно зросла, щоб уникнути впливу на інші бізнеси Paipai, і щоб уникнути впливу інших компаній, API тут розгортає дві машини окремо для них, nginx можна налаштувати так, щоб виснажувати доступ до віртуального API:
Віртуальний контейнер API: http://api.paipai.com/v2/virbiz
Таким чином, коли ми випускаємо версію, спочатку можемо обрати Yixun з найменшим обсягом бізнесу для публікації, а потім переконатися, що проблем немає, перш ніж використовувати всі інші платформи.
2. Розгортання шляхом ізоляції користувача
Це не дуже підходить для відкритих платформ, але дуже підходить для прикладних сценаріїв, таких як SNS. Наприклад, система QQ поділена на кілька наборів відповідно до сегментів числа користувачів, і кожен набір містить 100 мільйонів послідовних чисел. Якщо припустити, що останнє число QQ близько до 1 мільярда, загалом існує 10 наборів (від Набору 1 до Набору 10). Таким чином, ви можете обирати один із SETS для публікації кожного разу, а високорівневий QQ часто не є дуже важливим користувачем, тому SET10 буде випущений першим.
Заслуга
Ізольоване впровадження з мінімальним впливом на бізнес-напрямки. Автоматично підтримує публікацію в відтінках сірого.
Недолік
Гранулярність відтінків сірого залежить від гранулярності ізольованого розгортання, яке зазвичай є великим.
Марна трата машин у порівнянні з централізованим розгортанням.
Версії кожної бізнес-лінії можуть бути непослідовними, що не сприяє уніфікованому управлінню.
Існують певні витрати на впровадження та розгортання
Схема 4: Динамічна маршрутизація
Метод: Використовуйте політику відтінків сірого, яку можна гнучко налаштувати так, щоб впливати на поведінку балансу навантаження та дозволяти йому повертати IP та порт сервісу grayscale відповідно до політики gray-scale.
Підходить для сервісних відтінків сірого з бек-офісним IDL.
Заслуга
Гнучкий, керований.
Недолік
Поточний центр конфігурації та сам L5 не враховують визначені політики маршрутизації і не є масштабованими, тому їх потрібно розробляти поза ними.
Джерела метаданих API досить розкидані, і наразі метадані API та IDL, рівні API та частотні обмеження розподілені між різними джерелами даних, тому тепер необхідно додати джерело маршрутизації в відтінках сірого.
Зазвичай існує три способи публікації відтінків сірого nginx+lua, nginx розподіляється відповідно до cookie, а nginx призначається за вагою:
nginx+lua розрізняється за IP-адресою відвідувача, оскільки компанія експортує IP-адресу, і сайт буде доступний або зі старою, або новою версією, яка не підходить для цього методу
nginx призначає ваги на основі ваг, що легко реалізувати і можна спробувати
nginx розділяється на основі cookie, а grayscale публікує за користувачами
|
Опубліковано 09.03.2017 15:48:27
|
|
|
|
