Логирај се Отвори нов тикет

Нашата најсложена и најнапредна имплементација на веб архитектура

Имавме за задача да направиме архитектура за wayglobal.com, која слободно и без некакви посебни побарувања би можела да биде хоризонтално надоградена. Има два типа надоградби, вертикална и хоризонтална надоградба.

Вертикална надоградба преставува зголемување на процесорот, рамот, дискот, линијата и слично, но за еден сервер. Овој тип на надоградба е прилично лесен бидејќи всушност се зависи од самиот хардвер на серверот.

Хоризонталната надоградба е прилично слошена, не само од аспект на харвер туку и од аспект на самото работење на веб апликацијата. Нашиот систем на хоризонтална надоградба може да се подели на неколку дела и тоа:

  1. DNS сервер
  2. Load balancing сервер
  3. Веб сервери
  4. Email сервери
  5. Сервери за складирање на податоци
  6. Сервери за дистрибуција на податоци
  7. Distributed Cache
  8. Дата база сервери

 

Сето ова презентирано на слика би изгледало вака:

 

 

Да го објасниме целиот процес од кога корисникот влегува на веб сајтот се до крајниот процес т.е кога корисникот веќе ја гледа веб страната.

 

Најпрво, корисникот го испушува доменот на веб сајтот, на пример www.gohost.mk. Секој домен си има своја IP адреса кон која поентира. За да се дознае IP адресата, мора барањето да отиде до DNS серверот конфигуриран на неговата мрежа и доколку неговиот DNS сервер нема информации за IP адресата, тогаш барањето ќе проба да ја дознае IP адресата од нашите DNS сервери. Бидејќи користиме повеќе DNS сервери ширум светот, барањето ќе отиде до најблискиот, се со цел барањето да биде брзо. Нашиот DNS сервер ќе му врати повратна информација со IP адреса до load balancer серверот.

Кога барањето ќе стигне до load balancer серверот, овој сервер има за задача да го префрли барањето до некој од веб серверите. Овој процес може да биде доста сложен бидејќи има многу начини како load balancer серверот да одлучи кон кој веб сервер да го испрати барањето. Но наједноставно да ви објасниме е тоа дека секое барање оди на следниот веб сервер. Значи првото барање ќе отиде на веб сервер 1, второто на веб сервер 2, третото на веб сервер 3, четвртото на веб сервер 1 итн.

Кога барањето ќе стигне до веб серверот, апликацијата има за задача да изгенерира html кој ќе му го испрати назад на корисникот. Доколку е потребно, апликацијата може да се конектира до веб базите за да земе некои информации од база или може да земе некои податоци од distributete cache серверите. Вака генерираниот html му е испратен назад на корисникот, а за сите други потребни фајлови при рендерирање на страната, користиме CDN. Ова значи дека сите слики, јаваскрипти и други фајлови корисникот ќе ги превземе од најблискиот CDN сервер. Значи, брзината за сите останати фајлови освен главниот, така наречен index.html е скоро иста за корисник од Америка, Евопа или Азија.

Главната поента на целата архитектура е следнава: 

  1. Брзината на сајтот да биде скоро иста за било кој корисник без разлика од кој континент е.
  2. Доколку се потребни повеќе веб сервери, додавањето на нов вер сервер е прилично лесно, а воедно и доколку се расипе или угаси некој веб сервер, апликацијата си продолжува да работи. Истото важи и за датабаза серверите, distributet cache, email,storage, cdn и dns серверите.

Ова во интернет светот се вика: no single point of failure.

 

Технички карактеристики

Еден веб сервер користи:

  1. Windows 2012 Standard
  2. IIS 8
  3. Lucene Index. Секој веб сервер си има свој индекс за пребарување. Не се одлучивме за дистрибуиран систем за пребарување поради x причини.
  4. OpenOffice - За конвертирање на различни типови на документи во PDF.
  5. Апликација за синхронизирање на времето со другите веб сервери. Бидејќи користиме Quartz.net, имавме проблем со синхронизацијата на времето, бидејќи разликата повеќе времето на сите веб сервери не требаше да биде поголемо од 1 секунда.

Еден датабаза сервер користи:

  1. Centos OS
  2. MongoDB

 

Load balancer серверот користи HAproxy софтвер. Успешно имплементиравме и SSL во HAproxy дури кога оваа опција беше во "изработка" статус.

За DNS користиме Route 53 услуга од Amazon.

За складирање на податоците користиме S3 услуга од Амазон.

За дистрибуција на податоците користиме CloudFront услуга од амазон.

За емаил користиме SNS услуга од Amazon.

За distributete cache користиме Memcached датабаза и Centos OS.

 

Проблеми при имплементација: 

 

  1. Разликата на времето кај сите веб сервери не требаше да биде поголемо од 1 секунда.
  2. При додавање на слика од страна на корисникот, сликата моравме да ја зачуваме во датабаза бидејќи при испраќање (POST), другиот веб сервер ја немаше сликата на самиот диск.
  3. За среќа, тогаш беше објавена новата верзија на HAproxy во која беше презентирана новата опција за SSl, во спротивно ќе требаше да имплементираме нов сервер кој би користел Nginx или Stunnel.
  4. Бидејќи Memcached клиентот користи consistent hashing алгоритам за да дознае кој клуч на кој сервер е и при рестарирање на еден од cache серверите, ист клуч можете да се најде на два сервери. Затоа таму чуваме само информации кои дури и да не се точни, нема да има поголема грешка во апликацијата. Едно време размислувавме при fail на одреден сервер, да направиме скрипта која ќе ги брише сите податоци на тој сервер, без разлика дали грешката настанала поради рестартирање на серверот, проблеми при конекција или проблеми на апликативно ниво.

 

За секое ниво од имплементацијата може да се пишува со денови, но накратко ви објаснивме како имплементиравме една веб архитектура која е на едно максимално технолошко ниво.