Архитектура Stack Overflow версия 2020


Оглавление (нажмите, чтобы открыть):

Профессиональная конференция разработчиков высоконагруженных систем

Marco Cecconi is a core team software developer at Stack Overflow and a public speaker focused on architecture and development. As a speaker he has participated to, or is scheduled at, DevDay (Poland), Webtech.de and Developer Conference (Germany), Hacker News London, How To Web (Romania), Community Days (keynote, Italy), QCon China (keynote), QCon Japan.

Stack Overflow, and its Q&A network Stack Exchange, have been growing exponentially for the last five years. They now encompass

9 million users

13 million questions

22 million answers

In this talk, I will describe:
* The physical architecture of Stack Overflow. How many servers are there? What is their purpose and what are their specs?
* The logical architecture of the software. How do we scale up? What are the main building blocks of our software?
* The tooling system. What supports our extreme optimization philosophy?
* The development team. What are our core values? What footprint do we want to leave as developers?

База знаний для программистов Stack Overflow запустила сервис для обсуждения вопросов разработки внутри компаний Материал редакции

Новая услуга дешевле существующей корпоративной версии и подходит для небольших команд.

Сервис вопросов и ответов для программистов Stack Overflow запустил ещё одну корпоративную версию продукта Stack Overflow for Teams, которая позволяет использовать платформу для обсуждения разработки внутри компании. Об этом пишет VentureBeat.

Stack Overflow for Teams предназначена для групп от пяти до 500 человек, но строгих ограничений нет и при необходимости команды могут зарегистрировать больше или меньше участников. Решение подойдёт для компаний, которые хотят обсудить разработку или провести обучение новых членов команды, но не готовы обсуждать используемый код публично, объяснил гендиректор Stack Overflow Джоэл Спольски.

Версия Stack Overflow for Teams стоит $10 в месяц за десять пользователей, за каждого дополнительного участника придётся платить $5 в месяц или $50 в год. Компания также готовится представить версию Stack Overflow for Teams для некоммерческих организаций и проектов с открытым исходным кодом.

Групповые вопросы хранятся в отдельной базе данных, но участники команды видят их на основном сайте Stack Overflow. Когда пользователь задаёт вопрос, он может выбрать, куда его направить: своей команде или глобальному сообществу разработчиков. Если вопрос адресован команде, есть возможность отметить людей, которые смогут на него ответить, — им будет отправлено уведомление о вопросе.

У Stack Overflow уже есть корпоративная версия Enterprise, но это дорогостоящий продукт (около $200 за пользователя в год), который предполагает многолетний контракт и используется крупными компаниями вроде Bloomberg и Microsoft. Спольски рекомендует Enterprise компаниям, в которых работают тысячи разработчиков.

Stack Overflow: The Architecture — 2020 Edition

To get an idea of what all of this stuff “does,” let me start off with an update on the average day at Stack Overflow. So you can compare to the previous numbers from November 2013, here’s a day of statistics from February 9th, 2020 with differences since November 12th, 2013:

  • 209,420,973 (+61,336,090) HTTP requests to our load balancer
  • 66,294,789 (+30,199,477) of those were page loads
  • 1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB) of HTTP traffic sent
  • 569,449,470,023 (+282,874,825,991) bytes (569 GB) total received
  • 3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB) total sent
  • 504,816,843 (+170,244,740) SQL Queries (from HTTP requests alone)
  • 5,831,683,114 (+5,418,818,063) Redis hits
  • 17,158,874 (not tracked in 2013) Elastic searches
  • 3,661,134 (+57,716) Tag Engine requests
  • 607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries
  • 10,396,073 (-88,950,843) ms (2.8 hours) spent on Redis hits
  • 147,018,571 (+14,634,512) ms (40.8 hours) spent on Tag Engine requests
  • 1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net
  • 22.71 (-5.29) ms average (19.12 ms in ASP.Net) for 49,180,275 question page renders
  • 11.80 (-53.2) ms average (8.81 ms in ASP.Net) for 6,370,076 home page renders

You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That’s due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves. Please don’t forget: performance is still a feature. If you’re curious about more hardware specifics than I’m about to provide—fear not. The next post will be an appendix with detailed hardware specs for all of the servers that run the sites (I’ll update this with a link when it’s live).

So what’s changed in the last 2 years? Besides replacing some servers and network gear, not much. Here’s a top-level list of hardware that runs the sites today (noting what’s different since 2013):

  • 4 Microsoft SQL Servers (new hardware for 2 of them)
  • 11 IIS Web Servers (new hardware)
  • 2 Redis Servers (new hardware)
  • 3 Tag Engine servers (new hardware for 2 of the 3)
  • 3 Elasticsearch servers (same)
  • 4 HAProxy Load Balancers (added 2 to support CloudFlare)
  • 2 Networks (each a Nexus 5596 Core + 2232TM Fabric Extenders, upgraded to 10Gbps everywhere)
  • 2 Fortinet 800C Firewalls (replaced Cisco 5525-X ASAs)
  • 2 Cisco ASR-1001 Routers (replaced Cisco 3945 Routers)
  • 2 Cisco ASR-1001-x Routers (new!)

What do we need to run Stack Overflow? That hasn’t changed much since 2013, but due to the optimizations and new hardware mentioned above, we’re down to needing only 1 web server. We have unintentionally tested this, successfully, a few times. To be clear: I’m saying it works. I’m not saying it’s a good idea. It’s fun though, every time.

Now that we have some baseline numbers for an idea of scale, let’s see how we make those fancy web pages. Since few systems exist in complete isolation (and ours is no exception), architecture decisions often make far less sense without a bigger picture of how those pieces fit into the whole. That’s the goal here, to cover the big picture. Many subsequent posts will do deep dives into specific areas. This will be a logistical overview with hardware highlights only; the next post will have the hardware details.

For those of you here to see what the hardware looks like these days, here are a few pictures I took of rack A (it has a matching sister rack B) during our February 2015 upgrade:

…and if you’re into that kind of thing, here’s the entire 256 image album from that week (you’re damn right that number’s intentional). Now, let’s dig into layout. Here’s a logical overview of the major systems in play:

Ground Rules

Here are some rules that apply globally so I don’t have to repeat them with every setup:

  • Everything is redundant.
  • All servers and network gear have at least 2x 10Gbps connectivity.
  • All servers have 2 power feeds via 2 power supplies from 2 UPS units backed by 2 generators and 2 utility feeds.
  • All servers have a redundant partner between rack A and B.
  • All servers and services are doubly redundant via another data center (Colorado), though I’m mostly talking about New York here.
  • Everything is redundant.

The Internets

First, you have to find us—that’s DNS. Finding us needs to be fast, so we farm this out to CloudFlare (currently) because they have DNS servers nearer to almost everyone around the world. We update our DNS records via an API and they do the “hosting” of DNS. But since we’re jerks with deeply-rooted trust issues, we still have our own DNS servers as well. Should the apocalypse happen (probably caused by the GPL, Punyon, or caching) and people still want to program to take their mind off of it, we’ll flip them on.

After you find our secret hideout, HTTP traffic comes from one of our four ISPs (Level 3, Zayo, Cogent, and Lightower in New York) and flows through one of our four edge routers. We peer with our ISPs using BGP (fairly standard) in order to control the flow of traffic and provide several avenues for traffic to reach us most efficiently. These ASR-1001 and ASR-1001-X routers are in 2 pairs, each servicing 2 ISPs in active/active fashion—so we’re redundant here. Though they’re all on the same physical 10Gbps network, external traffic is in separate isolated external VLANs which the load balancers are connected to as well. After flowing through the routers, you’re headed for a load balancer.

I suppose this may be a good time to mention we have a 10Gbps MPLS between our 2 data centers, but it is not directly involved in serving the sites. We use this for data replication and quick recovery in the cases where we need a burst. “But Nick, that’s not redundant!” Well, you’re technically correct (the best kind of correct), that’s a single point of failure on its face. But wait! We maintain 2 more failover OSPF routes (the MPLS is #1, these are #2 and 3 by cost) via our ISPs. Each of the sets mentioned earlier connects to the corresponding set in Colorado, and they load balance traffic between in the failover situation. We could make both sets connect to both sets and have 4 paths but, well, whatever. Moving on.

Load Balancers (HAProxy)

The load balancers are running HAProxy 1.5.15 on CentOS 7, our preferred flavor of Linux. TLS (SSL) traffic is also terminated in HAProxy. We’ll be looking hard at HAProxy 1.7 soon for HTTP/2 support.

Unlike all other servers with a dual 10Gbps LACP network link, each load balancer has 2 pairs of 10Gbps: one for the external network and one for the DMZ. These boxes run 64GB or more of memory to more efficiently handle SSL negotiation. When we can cache more TLS sessions in memory for reuse, there’s less to recompute on subsequent connections to the same client. This means we can resume sessions both faster and cheaper. Given that RAM is pretty cheap dollar-wise, it’s an easy choice.

The load balancers themselves are a pretty simple setup. We listen to different sites on various IPs (mostly for certificate concerns and DNS management) and route to various backends based mostly on the host header. The only things of note we do here is rate limiting and some header captures (sent from our web tier) into the HAProxy syslog message so we can record performance metrics for every single request. We’ll cover that later too.


Web Tier (IIS 8.5, ASP.Net MVC 5.2.3, and .Net 4.6.1)

The load balancers feed traffic to 9 servers we refer to as “primary” (01-09) and 2 “dev/meta” (10-11, our staging environment) web servers. The primary servers run things like Stack Overflow, Careers, and all Stack Exchange sites except meta.stackoverflow.com and meta.stackexchange.com, which run on the last 2 servers. The primary Q&A Application itself is multi-tenant. This means that a single application serves the requests for all Q&A sites. Put another way: we can run the entire Q&A network off of a single application pool on a single server. Other applications like Careers, API v2, Mobile API, etc. are separate. Here’s what the primary and dev tiers look like in IIS:

Here’s what Stack Overflow’s distribution across the web tier looks like in Opserver (our internal monitoring dashboard):

…and here’s what those web servers look like from a utilization perspective:

I’ll go into why we’re so overprovisioned in future posts, but the highlight items are: rolling builds, headroom, and redundancy.

Service Tier (IIS, ASP.Net MVC 5.2.3, .Net 4.6.1, and HTTP.SYS)

Behind those web servers is the very similar “service tier.” It’s also running IIS 8.5 on Windows 2012R2. This tier runs internal services to support the production web tier and other internal systems. The two big players here are “Stack Server” which runs the tag engine and is based on http.sys (not behind IIS) and the Providence API (IIS-based). Fun fact: I have to set affinity on each of these 2 processes to land on separate sockets because Stack Server just steamrolls the L2 and L3 cache when refreshing question lists on a 2-minute interval.

These service boxes do heavy lifting with the tag engine and backend APIs where we need redundancy, but not 9x redundancy. For example, loading all of the posts and their tags that change every n minutes from the database (currently 2) isn’t that cheap. We don’t want to do that load 9 times on the web tier; 3 times is enough and gives us enough safety. We also configure these boxes differently on the hardware s >/questions/tagged/java , you’re hitting the tag engine to see which questions match. It does all of our tag matching outs >/search , so the new navigation, etc. are all using this service for data.

Cache & Pub/Sub (Redis)

We use Redis for a few things here and it’s rock solid. Despite doing about 160 billion ops a month, every instance is below 2% CPU. Usually much lower:

We have an L1/L2 cache system with Redis. “L1” is HTTP Cache on the web servers or whatever application is in play. “L2” is falling back to Redis and fetching the value out. Our values are stored in the Protobuf format, via protobuf-dot-net by Marc Gravell. For a client, we’re using StackExchange.Redis—written in-house and open source. When one web server gets a cache miss in both L1 and L2, it fetches the value from source (a database query, API call, etc.) and puts the result in both local cache and Redis. The next server wanting the value may miss L1, but would find the value in L2/Redis, saving a database query or API call.

We also run many Q&A sites, so each site has its own L1/L2 caching: by key prefix in L1 and by database ID in L2/Redis. We’ll go deeper on this in a future post.

Alongside the 2 main Redis servers (master/slave) that run all the site instances, we also have a machine learning instance slaved across 2 more dedicated servers (due to memory). This is used for recommending questions on the home page, better matching to jobs, etc. It’s a platform called Providence, covered by Kevin Montrose here.

The main Redis servers have 256GB of RAM (about 90GB in use) and the Providence servers have 384GB of RAM (about 125GB in use).

Redis isn’t just for cache though, it also has a publish & subscriber mechanism where one server can publish a message and all other subscribers receive it—including downstream clients on Redis slaves. We use this mechanism to clear L1 caches on other servers when one web server does a removal for consistency, but there’s another great use: websockets.

Websockets (https://github.com/StackExchange/NetGain)

We use websockets to push real-time updates to users such as notifications in the top bar, vote counts, new nav counts, new answers and comments, and a few other bits.

The socket servers themselves are using raw sockets running on the web tier. It’s a very thin application on top of our open source library: StackExchange.NetGain . During peak, we have about 500,000 concurrent websocket connections open. That’s a lot of browsers. Fun fact: some of those browsers have been open for over 18 months. We’re not sure why. Someone should go check if those developers are still alive. Here’s what this week’s concurrent websocket pattern looks like:

Мастер Йода рекомендует:  WebStorm, популярная IDE для JS-разработки, обновилась до версии 2020.1

Why websockets? They’re tremendously more efficient than polling at our scale. We can simply push more data with fewer resources this way, while being more instant to the user. They’re not without issues though—ephemeral port and file handle exhaustion on the load balancer are fun issues we’ll cover later.

Search (Elasticsearch)

Spoiler: there’s not a lot to get excited about here. The web tier is doing pretty vanilla searches against Elasticsearch 1.4, using the very slim high-performance StackExchange.Elastic client. Unlike most things, we have no plans to open source this simply because it only exposes a very slim subset of the API we use. I strongly believe releasing it would do more harm than good with developer confusion. We’re using elastic for /search , calculating related questions, and suggestions when asking a question.

Each Elastic cluster (there’s one in each data center) has 3 nodes, and each site has its own index. Careers has an additional few indexes. What makes our setup a little non-standard in the elastic world: our 3 server clusters are a bit beefier than average with all SSD storage, 192GB of RAM, and dual 10Gbps network each.

The same application domains (yeah, we’re screwed with .Net Core here…) in Stack Server that host the tag engine also continually index items in Elasticsearch. We do some simple tricks here such as ROWVERSION in SQL Server (the data source) compared against a “last position” document in Elastic. Since it behaves like a sequence, we can simply grab and index any items that have changed since the last pass.

The main reason we’re on Elasticsearch instead of something like SQL full-text search is scalability and better allocation of money. SQL CPUs are comparatively very expensive, Elastic is cheap and has far more features these days. Why not Solr? We want to search across the entire network (many indexes at once), and this wasn’t supported at decision time. The reason we’re not on 2.x yet is a major change to “types” means we need to reindex everything to upgrade. I just don’t have enough time to make the needed changes and migration plan yet.

Databases (SQL Server)

We’re using SQL Server as our single source of truth. All data in Elastic and Redis comes from SQL Server. We run 2 SQL Server clusters with AlwaysOn Availability Groups. Each of these clusters has 1 master (taking almost all of the load) and 1 replica in New York. Additionally, they have 1 replica in Colorado (our DR data center). All replicas are asynchronous.

The first cluster is a set of Dell R720xd servers, each with 384GB of RAM, 4TB of PCIe SSD space, and 2x 12 cores. It hosts the Stack Overflow, Sites (bad name, I’ll explain later), PRIZM, and Mobile databases.

The second cluster is a set of Dell R730xd servers, each with 768GB of RAM, 6TB of PCIe SSD space, and 2x 8 cores. This cluster runs everything else. That list includes Talent, Open ID, Chat, our Exception log, and every other Q&A site (e.g. Super User, Server Fault, etc.).

CPU utilization on the database tier is something we like to keep very low, but it’s actually a little high at the moment due to some plan cache issues we’re addressing. As of right now, NY-SQL02 and 04 are masters, 01 and 03 are replicas we just restarted today during some SSD upgrades. Here’s what the past 24 hours looks like:

Our usage of SQL is pretty simple. Simple is fast. Though some queries can be crazy, our interaction with SQL itself is fairly vanilla. We have some legacy Linq2Sql, but all new development is using Dapper, our open source Micro-ORM using POCOs. Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.

Libraries

Okay, let’s change gears to something that can more directly help you. I’ve mentioned a few of these up above, but I’ll provide a list here of many open-source .Net libraries we maintain for the world to use. We open sourced them because they have no core business value but can help the world of developers. I hope you find these useful today:

  • Dapper (.Net Core) — High-performance Micro-ORM for ADO.Net
  • StackExchange.Redis — High-performance Redis client
  • MiniProfiler — Lightweight profiler we run on every page (also supports Ruby, Go, and Node)
  • Exceptional — Error logger for SQL, JSON, MySQL, etc.
  • Jil — High-performance JSON (de)serializer
  • Sigil — A .Net CIL generation helper (for when C# isn’t fast enough)
  • NetGain — High-performance websocket server
  • Opserver — Monitoring dashboard polling most systems directly and feeding from Orion, Bosun, or WMI as well.
  • Bosun — Backend monitoring system, written in Go

Next up is a detailed current hardware list of what runs our code. After that, we go down the list. Stay tuned.

Как стать full-stack разработчиком в 2020 году

Традиционно разработчики делятся на front-end разработчиков и back-end разработчиков; это обусловлено разделением ответственности между внешним представлением проекта (front-end) и внутренними технологиями (back-end). Очень грубо обобщая, можно сказать, что фронтэнд разрабатывает интерфейс, который видят пользователи, а бэкенд делает «начинку», т.е. программно-аппаратную часть. Такое деление является логичным и создано для упрощения разработки проекта. Однако все чаще в IT-среде появляются full-stack разработчики. О том, кто они такие, и какие технологии актуальны для фулстек разработчика, я расскажу ниже.

Определение


Full-stack developer (или фулстек разработчик) – это разработчик, который должен разбираться во всем стеке технологий и используемых в проекте компонентов, как в части фронтенда, так и бэкенда. При этом такому разработчику совсем необязательно глубоко знать абсолютно все технологии, то есть речь не идет о том, что быть senior во всех технологиях, которые используются при разработке приложения.

Как правило, фулстек разработчик должен полностью закрывать весь стек разработки, в том числе разбираться в серверах, операционных системах и разных базах данных, а также PaaS.

Но если и упрощенное понятие фулстека: фулстек разработчик WordPress – это разработчик, который может делать и развертывать сайты на WordPress.

В общем, определение такого разработчика и требования к нему могут разниться.

Фулстек разработчик имеет свои планы и минусы.

Плюсы :

  • знание многих технологий дает возможность выбрать, куда двигаться дальше, проще перепрофилироваться;
  • в целом работа разнообразна, так как есть возможность менять проекты, пробовать разные варианты и технологии;
  • фулстек разработчики понимают работу многих технологий и поэтому могут выбрать хорошее решение для проекта, исправить недочеты и так далее.

Минусов , конечно, тоже хватает:

  • по сравнению с узкоспециализированным разработчиком, у фулстек разработчика меньше знаний в каждой из областей (то есть его знания работают вширь, а не вглубь);
  • из предыдущего пункта вытекает то, что ему сложнее развиваться – приходится осваивать все и сразу, а не концентрироваться на развитии в одном направлении;
  • у фулстек разработчика часто отсутствует одна, фиксированная зона ответственности, и из-за этого его еще сложно заменить другим специалистом;
  • нужно уметь хорошо планировать свою работу для того, чтобы все и везде успевать – иначе появиться риск перегрузки задачами (когда везде надо успеть все посмотреть, все сделать и т.д.).

Если, несмотря на это, вы все равно решили стать футстек разработчиком, то ниже я перечислю актуальные (на данный момент) технологии, которые вам обязательно нужно выучить.

HTML/CSS

Это – основа основ. Любой вебразработчик должен знать HTML и CSS. HTML позволяет добавлять данные, контент на сайт, а CSS отвечает за стиль этого контента. Темы, которые чаще всего затрагиваются при разговоре о HTML/CSS во время собеседования:

JavaScript

JavaScript (JS) – язык, который с каждым годом становится все популярнее и обрастает все большим количеством библиотек, фреймворков и инструментов.

Интересно, что в опросе Stack Overflow 2020 года JS стал самым популярным языком во всех трех областях: full stack, frontend и backend. В опросе 2020 года JS просто стал самым популярным языком из всех языков программирования. Ничего удивительного в этом нет – JS единственный язык программирования, который используется и в браузере, и может использоваться в качестве серверного языка (благодаря Node.js). В качестве фулстек разработчика нужно разбираться в следующих темах:

  • Работа с DOM . Также желательно знать, что такое и уметь использовать JSON
  • Важные особенности языка: композиция функций , наследование классов , делегирование событий , функции высшего порядка .
  • Порядок обработки событий (в том числе асинхронный), промисы и колбэки (функции обратного вызова)
  • Правильное структурирование кода и работа с модулями
  • Знание webpack , browserify и gulp
  • Знание хотя бы одного популярного фреймворка ( React , AngularJS …). Вообще понимание самого JS важнее, чем знание фреймворков, т.к. в любом из них тогда будет несложно разобраться
  • Знание jQuery
  • Автоматическое тестирование

Язык бэкенда

Теперь надо перейти к бэкенду, который отвечает за работу с базой данных, аутентификацию пользователей и логику работы приложения в целом. Здесь есть такой момент, что, по сути, не так важно, какой язык вы выберете, главное – это действительно понимать его и знать все его нюансы. Если задать на какой-нибудь популярной площадке вопрос о том, какой язык бэкенда лучше всего выучить и использовать, то разброс ответов будет широким: про каждый язык вы услышите и хорошее, и плохое.

Поэтому ниже я перечислю все популярные языки бэкенда.

Важное уточнение: вне зависимости от того, какой язык вы решите в итоге изучать, главное – продолжайте изучать именно его и узнавать все его тонкости, а не распыляться сразу на несколько вариантов.

  • Node.js : хороший вариант, т.к. сам по себе Node.js – это просто окружение JS, то есть при знании JS не нужно будет учить новый язык программирования. А самый популярный для изучения и создания приложений фреймворк – это Express .
  • Ruby : еще один популярный для бэкенда язык. Самые популярные фреймворки: Ruby on Rails и Sinatra .
  • Python : популярные фреймворки – Django и Flask .
  • Java : сейчас Java уже редко изучают для применения в бэкенде, однако компании, которые его до сих пор используют, существуют, поэтому найти работу можно и с этим языком программирования.
  • PHP : сейчас является краегольным камнем в вебе, но конкретно в бэкенде используется нечасто.

Базы данных и веб-хранилища

Во время изучения веб-разработки вы рано или поздно придете к тому, что данные нужно где-то хранить, а также нужно иметь возможность получить к ним доступ позже.

Поэтому обязательно нужно углубиться в следующие темы, касающиеся БД и хранения данных:

HTTP и REST

HTTP — это протокол передачи данных прикладного уровня, он обеспечивает взаимодействие сети и пользователя. Например, если JS-код делает какой-либо AJAX-запрос к бэкенду на сервере, то это происходит посредством HTTP. Важные в этой части темы перечислены ниже:

Архитектура веб-приложения

После того, как вы познакомились с HTML/CSS, JavaScript, бэкендом, базами данных, а также HTTP/REST, время перейти к архитектуре веб-приложения. Для того, чтобы создать сложное приложение, вам нужно знать, как правильно структурировать код, как разделять файлы, где держать большие медиа-файлы, как структурировать данные в базе данных, где выполнять сложные задачи и так далее.

Конечно, обо всем этом можно прочитать в сети, однако наилучшем решением будет практика — и лучше всего работать не одному, а в команде.

Поэтому человек, который занимается разработкой более 7 лет, совсем необязательно знает CSS или JS лучше разработчика с двухлетним опытом работы. Однако чем больше опыт у специалиста, тем с большим количеством приложений он работал, а значит, больше узнать относительно архитектуры и дизайна приложений (помимо других важных вещей). Опыт дает возможность увидеть картинку целиком.

Однако пока вы в начале пути, ознакомьтесь со следующими темами:

  • Платформа как услуга , например Heroku и AWS .
  • MVC
  • Максимально изучать опыт других разработчиков (видео на английском):


Git — это система контроля версий, которая позволяет разработчикам, работающим над одним проектом, следить за изменениями, которые были внесены в код. Научиться использовать Git несложно, для этого посмотрите:

Заключение

Теперь вы знаете все основные темы, в которых нужно разбираться для того, чтобы носить звание фулстэк разработчика. Конечно же, теория — это хорошо, но в мире программирования наибольшую роль играет практика, так что не забывайте все прочитанное и услышанное обязательно пробовать и использовать в своей работе.

Архитектура Stack Overflow версия 2020

Update 2: Stack Overflow Architecture Update — Now At 95 Million Page Views A Month
Update: Startup – ASP.NET MVC, Cloud Scale & Deployment shows an interesting alternative approach for a Windows stack using ServerPath/GoGrid for a dedicated database machine, elastic VMs for the front end, and a free load balancer.

Stack Overflow is a much loved programmer question and answer site written by two guys nobody has ever heard of before. Well, not exactly. The site was created by top programmer and blog stars Jeff Atwood and Joel Spolsky. In that sense Stack Overflow is like a celebrity owned restaurant, only it should be around for a while. Joel estimates 1/3 of all the programmers in the world have used the site so they must be serving up something good.

I fell in deep like with Stack Overflow for purely selfish reasons, it helped me solve a few difficult problems that were jabbing my eyes out with pain. I also appreciate their no-apologies anthropologically based design philosophy. Use design to engineer in the behaviours you want to encourage and minimize the responses you want to discourage. It’s the conscious awareness of the mechanisms that creates such a satisfying synergy.

What is key about the Stack Overflow story for me is the strong case they make for scale up as a viable solution for a certain potentially large class of problems. The publicity these days is all going scale out using NoSQL databases.

If you need to Google scale then you really have no choice but to go the NoSQL direction. But Stack Overflow is not Google and neither are most sites. When thinking about your design options keep Stack Overflow in mind. In this era of multi-core, large RAM machines and advances in parallel programming techniques, scale up is still a viable strategy and shouldn’t be tossed aside just because it’s not cool anymore. Maybe someday we’ll have the best of both worlds, but for now there’s a big painful choice to be made and that choice decides your fate.

Joel boasts that for 1/10 the hardware they have performance comparable to similarly size sites. He wonders if these other sites have good programmers. Let’s see how they did it and you be the judge.

The Stats

Platform

Lessons Learned

This is a mix of lessons taken from Jeff and Joel and comments from their posts.

  • If you’re comfortable managing servers then buy them. The two biggest problems with renting costs were: 1) the insane cost of memory and disk upgrades 2) the fact that they [hosting providers] really couldn’t manage anything.
  • Make larger one time up front investments to avoid recurring monthly costs which are more expensive in the long term.
  • Update all network drivers. Performance went from 2x slower to 2x faster.
  • Upgrading to 48GB RAM required upgrading MS Enterprise edition.
  • Memory is incredibly cheap. Max it out for almost free performance. At Dell, for example, upgrading from 4G memory to 128G is $4378.
  • Stack Overflow copied a key part of the Wikipedia database design. This turned out to be a mistake which will need massive and painful database refactoring to fix. The refactorings will be to avoid excessive joins in a lot of key queries. This is the key lesson from giant multi-terabyte table schemas (like Google’s BigTable) which are completely join-free. This is significant because Stack Overflow’s database is almost completely in RAM and the joins still exact too high a cost.
  • CPU speed is surprisingly important to the database server. Going from 1.86 GHz, to 2.5 GHz, to 3.5 GHz CPUs causes an almost linear improvement in typical query times. The exception is queries which don’t fit in memory.
  • When renting hardware nobody pays list price for RAM upgrades unless you are on a month-to-month contract.
  • The bottleneck is the database 90% of the time.
  • At low server volume, the key cost driver is not rackspace, power, bandwidth, servers, or software; it is NETWORKING EQUIPMENT. You need a gigabit network between your DB and Web tiers. Between the cloud and your web server, you need firewall, routing, and VPN devices. The moment you add a second web server, you also need a load balancing appliance. The upfront cost of these devices can easily be 2x the cost of a handful of servers.
  • EC2 is for scaling horizontally, that is you can split up your work across many machines (a good idea if you want to be able to scale). It makes even more sense if you need to be able to scale on demand (add and remove machines as load increases / decreases).
  • Scaling out is only frictionless when you use open source software. Otherwise scaling up means paying less for licenses and a lot more for hardware, while scaling out means paying less for the hardware, and a whole lot more for licenses.
  • RAID-10 is awesome in a heavy read/write database workload.
  • Separate application and database duties so each can scale independently of the other. Databases scale up and the applications scale out.
  • Applications should keep state in the database so they scale horizontally by adding more servers.
  • The problem with a scale up strategy is a lack of redundancy. A cluster ads more reliability, but is very expensive when the individual machines are expensive.
  • Few applications can scale linearly with the number of processors. Locks will be taken which serializes processing and ends up reducing the effectiveness of your Big Iron.
  • With larger form factors like 7U power and cooling become critical issues. Using something between 1U and 7U might be easier to make work in your data center.
  • As you add more and more database servers the SQL Server license costs can be outrageous. So by starting scale up and gradually going scale out with non-open source software you can be in a world of financial hurt.

    Мастер Йода рекомендует:  18 бесплатных генераторов CSS-кнопок

    It’s true there’s not much about their architecture here. We know about their machines, their tool chain, and that they use a two-tier architecture where they access the database directly from the web server code. We don’t know how they implement tags, etc. If interested you’ll be able to glean some of this information from an explanation of their schema.

    Discussion

    Microsoft Stack Badge

    The Microsoft Stack Badge was earned because Stack Overflow uses the entire Microsoft Stack: OS, database, C#, Visual Studio, and ASP .NET. People are always interested in how MS compares to LAMP, but I don’t have many case studies to show them.


    Markus Frind of Plenty of Fish fame is often used as a Microsoft stack poster child, but since he explicitly uses as little of the stack as possible he’s not really a good example. Stack Overflow on the other hand is brash in proclaiming their love for MS, even when that love is occasionally spurned.

    It’s hard to separate out the Microsoft stack and the scale up approach because for licensing reasons they tend to go together. If you find yourself in the position of transitioning from scale up to scale out by adding dozens of cores, MS licensing will bite you.

    Licensing aside I personally find C#, Visual Studio, and .Net a very productive environment. C#/.Net is at least as good as Java/JVM. ASP .NET has always been a confusing mess to me. The knock against SQL Server is you have to pay for it and if that doesn’t bother you then it’s a solid choice. The Windows OS may not be as solid as other alternatives but it works well enough.

    So for a scale up solution a Microsoft stack works, especially if you are already Windows centric.

    Scale Up Badge

    This won’t be a reenactment of the scale out vs scale up vs rent vs buy wars. For a thorough discussion of these issues please take a look at Scaling Up vs. Scaling Out and Server Hosting — Rent vs. Buy?. If you aren’t confused and if your head doesn’t hurt after reading all that then you haven’t properly understood the material 🙂

    The Scale Up Badge was awarded because Stack Overflow uses a scale up strategy to meet their scaling requirements. When they reach a limit they scale vertically by buying a bigger machine and adding more memory.

    Stack Overflow is in the sweet spot for scale up. It’s not too large, but with an Alexa ranking of 1,666 and 16 million page views a month it’s still a substantial site. Not Google scale, and probably will never have to be, but those are numbers many sites would be thrilled to have. Yet they aren’t uploading large amounts of media. They aren’t dealing with billions of tweets across complex social networks with millions of users. Their number of users is self limiting. And there are still directions they can take if they need to scale (caching, more web servers, faster disks, more denormalization, more memory, some partitioning, etc). All-in-all it’s a well done and very useful two-tier CRUD application.

    NoSQL is Hard

    So should Stack Overflow have scaled out instead of up, just in case?

    What some don’t realize is NoSQL is hard. Relational databases have many many faults, but they make a lot of common tasks simple while hiding both the cost and complexity. If you want to know how many black Prius cars are in inventory, for example, then that’s pretty easy to do.

    Not so with most NoSQL databases (I’ll speak generally here, some NoSQL databases have more features than others). You would have program a counter of black Prius cars yourself, up front, in code. There are no aggregate operators. You must maintain secondary indexes. There’s no searching. There are no distributed queries across partitions. There’s no Group By or Order By. There are no cursors for easy paging through result sets. Returning even 100 large records at time may timeout. There may be quotas that are very restrictive because they must limit the amount of IO for any one operation. Query languages may lack expressive power.

    The biggest problem of all is that transactions can not span arbitrary boundaries. There are no ACID guarantees beyond a single record or small entity group. Once you wrap your head around what this means for the programmer it’s not a pleasant prospect at all. References must be manually maintained. Relationships must be manually maintained. There are no cascading deletes that act correctly during a failure. Every copy of denormalized data must be manually tracked and updated taking into account the possibility of partial failures and externally visible inconsistency.

    All this functionality must be written manually by you in your code. While flexibility to write your own code is great in an OLAP/map-reduce situation, declarative approaches still cover a lot of ground and make for much less brittle code.

    What you gain is the ability to write huge quantities of data. What you lose is complacency. The programmer must be very aware at all times that they are dealing with a system where it costs a lot to perform distribute operations and failure can occur at anytime.

    All this may be the price of building a truly scalable and distributed system, but is this really the price you want to pay?

    The Multitenancy Problem

    With StackExchange Stack Overflow has gone into the multi-tenancy business. They are offering StackExchange either self-hosted or as a hosted white label application.

    It will be interesting to see if their architecture can scale to handle a large number of sites. Salesorce is the king of multitenancy and although it’s true they use Oracle as their database, they basically use very little of Oracle and have written their own table structure, indexing and query processor on top of Oracle. All in order to support multitenancy.

    Salesforce went extreme because supporting a lot of different customers is way more difficult than it seems, especially once you allow customization and support versioning.

    Clearly all customers can’t run in one server for security, customization, and scaling reasons.

    You may think just create a database for each customer, share a server for a certain number of customers, and then add more servers as needed. As long as a customer doesn’t need more than one server you are golden.

    This doesn’t seem to work well in practice. Oddly database managers aren’t optimized for adding or updating databases. Creating databases is a heavyweight operation and can degrade performance for existing customers as system locks are taken. Upgrade issues are also problematic. Adding columns locks tables which causes problems in high traffic situations. Adding new indexes can also take a very long time and degrade performance. Plus each customer will likely have specializations that makes upgrading even more complicated.

    To get around these problems Salesforce’s Craig Weissman, Chief Architect, created an innovative approach where tables are not created for each customer. All data from all customers is mapped into the same data table, including indexes. The schema for that table looks something like orgid, oid, value0, value1. value500. «orgid» is the organization ID and is how data is never mixed up. It’s a very wide and sparse table, which Oracle seems to handle well. Hundreds and hundreds of «tables» and custom fields are mapped into the data table.

    With this approach Salesforce has no option other than to build their own infrastructure to interpret what’s in that table. Oracle is left to handle transactions, concurrency, and deadlock detection. The advatange is because there’s an interpreted layer handling versions and upgrades is relatively simple because the handling logic can be baked in. Strange but true.

    Related Articles

    This list includes a number of posts by Jeff as he chronicles their journey with Stack Overflow. Jeff is wonderful about being open about what they are doing and why. The comment threads are often tremendous. There’s a lot to learn.

    Stack Overflow: The Architecture – 2020 Edition

    To get an idea of what all of this stuff “does,” let me start off with an update on the average day at Stack Overflow. So you can compare to the previous numbers from November 2013, here’s a day of statistics from February 9th, 2020 with differences since November 12th, 2013:

    • 209,420,973 (+61,336,090) HTTP requests to our load balancer
    • 66,294,789 (+30,199,477) of those were page loads
    • 1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB) of HTTP traffic sent
    • 569,449,470,023 (+282,874,825,991) bytes (569 GB) total received
    • 3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB) total sent
    • 504,816,843 (+170,244,740) SQL Queries (from HTTP requests alone)
    • 5,831,683,114 (+5,418,818,063) Redis hits
    • 17,158,874 (not tracked in 2013) Elastic searches
    • 3,661,134 (+57,716) Tag Engine requests
    • 607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries
    • 10,396,073 (-88,950,843) ms (2.8 hours) spent on Redis hits
    • 147,018,571 (+14,634,512) ms (40.8 hours) spent on Tag Engine requests
    • 1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net
    • 22.71 (-5.29) ms average (19.12 ms in ASP.Net) for 49,180,275 question page renders
    • 11.80 (-53.2) ms average (8.81 ms in ASP.Net) for 6,370,076 home page renders

    You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That’s due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves. Please don’t forget: performance is still a feature. If you’re curious about more hardware specifics than I’m about to provide—fear not. The next post will be an appendix with detailed hardware specs for all of the servers that run the sites (I’ll update this with a link when it’s live).

    Read the rest of Stack Overflow: The Architecture – 2020 Edition on Nick’s blog here. It’s the start of an extensive series of blog posts on Stack Overflow’s technical architecture.

    Do you enjoy managing hardware? Then check out our network administrator and database administrator job listings.

    DB Architecture of stackoverflow [duplicate]

    I admire the instant responses of SO. I wonder how the database was built?

    What’s the architecture? You don’t need to disclose the exact thing but an idea to everyone will help.


    marked as duplicate by Ladybug Killer, Ólafur Waage, random, TheTXI Sep 25 ’09 at 12:19

    This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    migrated from stackoverflow.com Sep 25 ’09 at 9:43

    This question came from our site for professional and enthusiast programmers.

    Национальная библиотека им. Н. Э. Баумана
    Bauman National Library

    Персональные инструменты

    Stack Overflow

    Stack Overflow

    сервис «Вопрос – ответ»
    Available in Мультиязычный
    Owner Stack Exchange Network
    Created by Джоэл Спольски
    Commercial Да
    Registration Необязательная
    Users 50 млн.
    Launched 15 сентября 2008 год
    Current status Поддерживается
    Written in C#
    IP address 151.101.193.69

    Stack Overflow – это сайт вопросов и ответов для профессиональных разработчиков программного обеспечения, энтузиастов программирования и системных администраторов. Сайт создан и управляется сообществом. Сервис создает свободную библиотеку подробных ответов на любой прикладной вопрос по программированию и системному администрированию. [Источник 1]

    Содержание

    Информация с официального сайта

    Вопрос – ответ. Ничего лишнего.

    Это сайт вопросов и ответов для профессиональных программистов и энтузиастов. Он построен таким образом чтобы каждый мог найти для себя ответ.

    С помощью пользователей создается библиотека подробных ответов на каждый вопрос о программировании.

    Лучшие ответы поднимаются наверх, чтобы их было легче найти.

    Автор вопроса может пометить один из ответов «принятым».

    Принятие ответа не означает, что он лучший; это значит, что изложенное в нём решение помогло автору вопроса.

    Получайте ответы на детализированные и конкретные вопросы

    Вопросы задаются о реальной проблеме, с которой столкнулись пользователи. Описание проводится детально, описываются все цели и пути к ним.

    • Конкретных проблемах, касающихся программирования и системного администрирования.
    • Реальных проблемах, с которыми столкнулись пользователи в трудовой деятельности.

    Не все вопросы хорошо вписываются в наш формат. Избегайте вопросов, которые сильно зависят от мнения отвечающего или тех, которые способны спровоцировать обсуждение вместо ответов.

    Вопросы, которые необходимо улучшить могут оставаться закрытыми, пока их не исправят.

    Не задавайте вопросы…

    • Все, что не связано напрямую с программированием или системным администрированием.
    • Вопросы, предполагающие спорные или субъективные ответы.
    • Вопросы со множеством возможных ответов или требующие одного, но очень длинного ответа.

    Метки упрощают поиск интересных вопросов

    Все вопросы отмечены метками в соответствии с их тематикой. Каждый вопрос может иметь до пяти меток, если он относится сразу к нескольким тематикам.

    Нажмите на метку, чтобы увидеть все вопросы с ней, или просмотрите список меток, чтобы найти интересующую вас тему.

    Ваша репутация растет, когда люди голосуют за ваши сообщения.

    Репутация растет, когда другие участники голосуют за вопросы, ответы и правки.

    По мере получения репутации участнику будут открываться новые привилегии, например возможность голосовать, комментировать и даже редактировать сообщения других участников.

    Заработав большую репутацию, каждый участник получит доступ к специальным инструментам модератора. Пользователь сможет работать вместе с модераторами сообщества, чтобы следить за порядком на сайте.

    Улучшайте сообщения с помощью правок или комментариев

    Цель сервиса – собрать лучшие ответы на все вопросы, поэтому, если вам попадутся сообщения, требующие улучшения, вы можете отредактировать их.

    Используйте редактирование для исправления ошибок, улучшения форматирования и разъяснения смысла сообщения.

    Используйте комментарии, чтобы получить дополнительную информацию или уточнить вопрос или ответ.

    Вы всегда можете оставлять комментарии под своими вопросами и ответами. Когда репутация достигнет 50, каждый участник сможет комментировать сообщения других участников.


    Получайте знаки за достижения

    Знаки – это достижения, полученные за участие в жизни сайта. Они бывают трёх видов: бронзовые, серебряные и золотые.

    Собственно, каждый может получить знак, просто прочитав данную страницу. [Источник 1]

    Компания

    Основанное в 2008 году, Stack Overflow является крупнейшим и наиболее надежным онлайн-сообществом, в котором разработчики могут учиться, делиться своими знаниями и строить свою карьеру. Более 50 миллионов профессиональных и начинающих программистов посещают Stack Overflow каждый месяц, чтобы помочь решить проблемы кодирования, развить новые навыки и найти рабочие места.

    Stack Overflow сотрудничает с предприятиями, чтобы помочь им понять, нанять, привлечь и помочь разработчикам со всего мира. Продукты и услуги ориентированы на маркетинг для разработчиков, технический рекрутинг, исследования рынка и обмен корпоративными знаниями.

    Stack Overflow входит в сеть так называемых Stack Exchange сайтов, список которых можно видеть далее. [Источник 2]

    Офисы

    В Stack Overflow в настоящее время работают более 250 человек в головных офисах в Нью-Йорке, Лондоне и Мюнхене, а также удаленные работники из Израиля, Бразилии, Японии, Германии, Словении, Испании, Польши, Франции, России, Канады, Великобритании и других стран. Компания стремится к разнообразию на рабочем месте и в настоящее время нанимает на работу. [Источник 2]

    История

    История начинается в 2008 году, когда Джоэл Спольски, тогдашний генеральный директор Fog Creek Software и автор широко читаемого блога Joel on Software под названием Джефф Этвуд, также известный своим популярным блогом Coding Horror, решил создать сайт вопросов и ответов. Джоэл Спольски и Джефф Этвуд вместе запускают Stack Overflow.

    Мастер Йода рекомендует:  Как настроить сервер Apache на максимальную производительность

    В 2010 году серия инвестиция в размере 6 млн. долларов США во главе с Union Square Ventures. Запускается Stack Exchange Network, распределяя вопросы и ответы в стиле Stack Overflow по новым темам (в настоящее время 133).

    В 2011 году происходит запуск Stack Overflow Careers (теперь называется Stack Overflow Talent). По сути сервис поиска работы в IT. Вторая волна инвестиций размером $ 12 млн во главе с Index Ventures с участием Spark Capital и Union Square Ventures.

    В 2012 году Stack Overflow Careers запускает свой первый локализованный сайт для говорящих на немецком языке (год спустя к нему добавится французский).

    В 2013 году третья волна инвестиций размером $ 10 млн., возглавляемая венчурным фондом Bezos Expeditions.

    В 2014 году появляются мобильные приложения для Android и iOS. В этом же году Stack Overflow запускает локализованные сайты на португальском и японском языках.

    В 2015 году четвертая волна инвестиций размером $ 40 млн. под руководством Andreessen Horowitz с участием Index Ventures, Spark Capital и Union Square Ventures [Источник 2]

    Архитектура сервиса

    Чтобы понять, как работает сервис, давайте начнем с показателей Stack Overflow. Итак, ниже приводится статистика за 12 ноября 2013 и 9 февраля 2020 года:

    • 209,420,973 (+61,336,090) HTTP-запросов к нашему балансировщику нагрузки;
    • 66,294,789 (+30,199,477) страниц было загружено;
    • 1,240,266,346,053 (+406,273,363,426) битов (1.24 TБ) отосланного HTTP-трафика;
    • 569,449,470,023 (+282,874,825,991) битов (569 ГБ) всего получено;
    • 3,084,303,599,266 (+1,958,311,041,954) битов (3.08 ТБ) всего отослано;
    • 504,816,843 (+170,244,740) SQL-запросов (только из HTTP-запросов);
    • 5,831,683,114 (+5,418,818,063) обращений к Redis;
    • 17,158,874 (not tracked in 2013) поисков в Elastic;
    • 3,661,134 (+57,716) запросов Tag Engine;
    • 607,073,066 (+48,848,481) мс (168 часов) выполнения SQL-запросов;
    • 10,396,073 (-88,950,843) мс (2.8 часов) затрачено на обращение к Redis;
    • 147,018,571 (+14,634,512) мс (40.8 часов) затрачено на запросы к Tag Engine;
    • 1,609,944,301 (-1,118,232,744) мс (447 часов) затрачено на обработку в ASP.NET;
    • 22.71 (-5.29) мс в среднем (19.12 мс в ASP.Net) на формирование каждой из 49,180,275 запрошенных страниц;
    • 11.80 (-53.2) мс в среднем (8.81 мс в ASP.Net) на формирование каждой из 6,370,076 домашних страниц.

    Из-за модернизации оборудования в начале 2015 года и из-за некоторого изменения параметров в самих приложениях существенно сократилась продолжительность обработки в ASP.Net по сравнению с 2013 годом (когда было 757 часов) несмотря на прибавление 61 миллиона запросов в день.

    Вот укрупненный список хардверной части, которая обеспечивает работу ресурса:

    • 4 Microsoft SQL Servers (новое железо для 2-х из них);
    • 11 Web-серверов IIS (новое оборудование);
    • 2 сервера Redis (новое оборудование);
    • 3 сервера Tag Engine (новое оборудование для 2-х из 3-х);
    • 3 сервера Elasticsearch (те же, старые);
    • 4 балансировщика нагрузки HAProxy (добавлено 2 для поддержки CloudFlare);
    • 2 брандмауэра Fortinet 800C (вместо Cisco 5525-X ASAs);
    • 2 маршрутизатора Cisco ASR-1001 (вместо маршрутизаторов Cisco 3945);
    • 2 маршрутизатора Cisco ASR-1001-x (новые).

    Чтобы запустить Stack Overflow необходим только один web-сервер.

    Теперь, когда у нас есть некоторые числа для понятия масштаба, давайте рассмотрим, как это присходит. Так как немногие системы работают в полной изоляции, часто конкретные архитектурные решения почти не имеют смысла без общей картины того, как эти части взаимодействуют между собой.

    На рисунке 1 представлена логическая схема взаимодействия главных систем:

    Рисунок 1 – логическая схема взаимодействия главных систем

    Вот некоторые всеобще применяемые правила, поэтому буду повторять их для каждой системы:

    • Все резервировано.
    • Все сервера и сетевые устройства связаны между собой, по крайней мере, 2 x 10 ГБит/с каналами.
    • Все сервера имеют 2 входа питания и 2 подвода питания от 2-х ИБП, подключенных к двум генераторам и двум сетевым линиям.
    • Все сервера между рэками A и B имеют резервированного партнера (redundant partner).
    • Все сервера и сервисы дважды резервированы через другой дата-центр (Колорадо), хотя здесь я буду больше говорить о Нью-Йорке. [Источник 3]

    В сети Интернет

    Сначала Вы должны найти сайт – это DNS. Процесс нахождения нас должен быть быстрым, поэтому этим занимается CloudFlare, так как их серверы DNS ближе почти всех остальных DNS мира. Записи DNS обновляются через API, а они делают «хостинг» DNS. Однако, при этом, сервис имеет собственные DNS-сервера. Если произойдет апокалипсис (вероятно, вызванный GPL, Punyon или кэшированием), а люди все еще будут хотеть программировать, чтобы не думать о нем, сервис переключится на них.

    После того, как Вы найдете Stack Overflow, пойдет HTTP-трафик через одного из четырех Интернет провайдеров (Level 3, Zayo, Cogent, и Lightower в Нью-Йорке), и через один из наших четырех локальных маршрутизаторов. Для достижения максимальной эффективности, вместе с провайдерами используется BGP для управления трафиком и обеспечения нескольких путей его передачи. Маршрутизаторы ASR-1001 и ASR-1001-X объединены в 2 пары, каждая из которых обслуживает 2 провайдера в режиме активный/активный. Таким образом, обеспечивается резервирование. Хотя они подключены все к той же физической сети 10 Гбит/с, внешний трафик проходит по отдельным изолированным внешним VLAN, которые также подключены к балансировщикам нагрузки. После прохождения через маршрутизаторы, трафик направляется к балансировщикам нагрузки.

    Между двумя дата-центрами используется линия MPLS на 10 Гбит/с, но это напрямую не связано с обслуживанием сайта. Она служит для дублирования данных и их быстрого восстановления в случаях, когда нужна пакетная передача. Через провайдеров имеется еще две более отказоустойчивые линии OSPF (по стоимости MPLS – № 1, а это № 2 и 3). Каждое из упомянутых устройств быстрее подключается к соответствующему устройству в Колорадо, и при отказе они распределяют между собой сбалансированный трафик. Разработчики смогли заставить оба устройства соединяться с обоими устройствами 4-мя способами, но все они и так одинаково хороши. [Источник 3]

    Балансировщики нагрузки (HAProxy)


    Балансировщики нагрузки работают на HAProxy 1.5.15 под CentOS 7, предпочтительной разновидности Linux. HAProxy также ограничивает и трафик TLS (SSL).

    В отличие от всех других серверов с двойным сетевым подключением по LACP 10 Гбит/с, каждый балансировщик нагрузки имеет по 2 пары каналов 10 Гбит/с: одну для внешней сети и одну для DMZ. Для более эффективного управляемого согласования SSL эти «коробки» имеют память 64 ГБ или больше. Когда можно кэшировать в памяти больше сессий TLS для повторного использования, тратится меньше времени на образование нового соединения с тем же самым клиентом. Это означает, что можно возобновлять сессии и быстрее, и с меньшими затратами. Учитывая, что RAM в переводе на доллары довольно дешевая, это – легкий выбор.

    Сами балансировщики нагрузки – довольно простые устройства. Создается иллюзия, что разные сайты «сидят» на различных IP (в основном по вопросам сертификации и управления DNS), и маршрутизируются на различные выходные буфера основываясь, главным образом, на заголовках хоста. Единственными «знаменитыми» вещами, которые осуществляются, является ограничение скорости и некоторые захваты заголовков (отсылаемых с уровня веб-узлов) в сообщение системного журнала HAProxy. Поэтому можно делать запись метрик производительности для каждого запроса. [Источник 3]

    Проект СПДС

    Скачать

    Читать новости в почте

    Поиск

    СПДС GraphiCS

    СПДС GraphiCS версия 2020

    СПДС GraphiCS — кроссплатформенное приложение для разработки проектно-конструкторской документации в строгом соответствии с требованиями СПДС.

    Коммерческая версия СПДС GraphiCS 2020, сборка 2886, AutoCAD

    СПДС GraphiCS 2020 устанавливается на графические платформы:

    • AutoCAD 2013−2020.
    • AutoCAD Architecture 2013−2020.
    • Подробнее о технических требованиях СПДС GraphiCS 2020.
    32-х битный 64-х битный
    Отдельный инсталлятор

    Образ дистрибутивного диска

    Как установить?

    Процедура установки, запроса и активации лицензии пошагово описана в разделе Инструкции.

    Новые возможности версии 2020.2886.819

    • Реализована поддержка AutoCAD 2020.
    • Новый интерфейс.
    • Реализован размер-подобие.
    • Обновление базы элементов.
    • Подробнее о новых возможностях СПДС GraphiCS 2020.

    Как получить пробную версию?

    Для ознакомления с работой программного обеспечения СПДС GraphiCS доступна
    15-дневная временная лицензия, позволяющая изучить весь функционал продукта.

    Для получения временной лицензии скачайте дистрибутив и выполните процедуру лицензирования с временным ключом:

    Задайте вопрос менеджеру по СПДС GraphiCS
    Copyright © 2007-2020 АО «СиСофт Девелопмент»

    Статистический анализ пользователей Stackoverflow и GitHub: кого больше?

    Когда-то относительно недавно я опубликовал сокращенную версию этой статьи на хабрахабре, а сейчас откопал в отвалах породы на жестком диске полную ее версию. Этот пост представляет собой вполне официальный отчет по довольно поверхностному (то есть я не зарывался глубоко в систему рейтингов, например) статистическому анализу по пользователям двух популярных ресурсов — Stack Overflow (stackoverflow.com) и GitHub (github.com).

    Из каких стран больше всего пользователей? Пользователи каких стран коммитят чаще? А каково место России на этом празднике жизни? Кто виноват и что делать? — ответы на эти вопросы можно найти здесь.

    Актуальность данных — на 24 октября 2014 года, но, полагаю, что тенденции, в этих данных отраженные, будут актуальны еще долгое время. Если кому интересно — дайте знать в комментариях, я обновлю данные на нынешний год.

    Ну и, надеюсь, никого не введет в уныние сухость изложения ��

    А еще этот пост можно прочитать на английском. Впрочем, русская версия гораздо полнее.

    Введение

    Аудитория проекта Stack Overflow составляет 3 580 212 зарегистрированных пользователей (2014 год), GitHub – 3 955 191 зарегистрированный пользователь (2014).

    Для сообщества Stack Overflow были проанализированы статистические данные за 2013 и 2014 годы, для GitHub — за 2012, 2013 и 2014 годы.


    Данные по статистике не полны, так как не все пользователи уточняют страну проживания (около 25% для Stack Overflow и около 70% для GitHub не указали страну проживания), однако имеющихся данных достаточно для понимания общей ситуации и соотношений.

    Stack Overflow

    Пользователей, указавших страной проживания Россию – 11 319, что составляет 0,38% от общего числа пользователей. Учитывая, что около 25% пользователей не указывают страну проживания, можно предположить, что реальное количество россиян на данном ресурсе может быть в районе 15 000 пользователей или около 0.42% от общего числа пользователей. При этом доля уникальных незарегистрированных посетителей с российскими IP-адресами на ресурсе на 2014 год составила около 1.6% (11 место) от общего количества уникальных незарегистрированных посетителей (для сравнения – Голландия – 1,75%, Бразилия – 2,3%, Индия – 12,5%, Китай – 1,46%).

    По общему числу зарегистрированных пользователей Россия входит в топ-10 ресурса Stack Overflow (данные за 2014 год):

    Страна Число пользователей
    1 США 253452
    2 Индия 67297
    3 Великобритания 33395
    4 Германия 19706
    5 Канада 16685
    6 Китай 14234
    7 Австралия 12592
    8 Бразилия 12325
    9 Франция 12217
    10 Россия 11319

    На карте указано процентное соотношение количества зарегистрированных пользователей Stack Overflow по отношению к общему количеству жителей страны. Мне кажется, вполне очевидные результаты. Напомню, что у Китая всегда были проблемы с Великим Китайским Файрволом

    На данном ресурсе присутствует система “репутации”, где пользователь получает баллы репутации за ценные профессиональные советы. Пользователи с показателем репутации более 1000 считаются наиболее компетентными. Всего пользователей с показателем репутации более 1000 – 68044, что составляет 1,9% от всего количества пользователей.

    На 2014 год пользователей, указавших страной проживания Россию и имеющих репутацию более 1000 – 800 человек, что составляет 1,18% от общего числа пользователей с репутацией более 1000.

    При этом, в 2013 году пользователей, указавших страной проживания Россию и имеющих репутацию более 1000, было 447 человек, что составляло приблизительно 1,25% от общего числа пользователей, указавших страну проживания, в количестве 35786 человек.

    Сравнительная таблица топ-10 стран и количество зарегистрированных пользователей с репутацией больше 1000 за 2013 и 2014 годы:

    18000

    2013 2014
    Страна Число пользователей Страна Число пользователей
    1 США 9592 США
    2 Великобритания 2906 Великобритания 4182
    3 Индия 2005 Индия 3460
    4 Германия 1461 Германия 2434
    5 Канада 1397 Канада 1995
    6 Австралия 1260 Австралия 1612
    7 Франция 724 Франция 1178
    8 Швеция 637 Нидерланды 1075
    9 Россия 447 Швеция 880
    10 Польша 439 Россия 800

    На карте указан прирост количества пользователей с репутацией больше 1000 с 2013 по 2014 год. Забавно, что Китай не попал в топ-10

    GitHub

    На данном ресурсе пользователи размещают собственноручно созданные программы или скрипты, написанные на различных языках программирования. Чем более интересные и качественные программы пишет пользователь, тем больше последователей (других пользователей, следящих за деятельностью интересующего их пользователя) он привлекает.

    На июль 2012 года на ресурсе было размещено 6 826 827 программ/скриптов и их правок (коммитов). Пользователи, указавшие страной проживания Россию, разместили на ресурсе около 1,8% коммитов от их общего количества.

    По состоянию дел на 2013 год пользователями, указавшими место проживания (около 26% всех пользователей), было сделано около 28500000 коммитов (около 44% от общего числа коммитов в 65 000 000). Россияне ответственны за приблизительно 3,5% от данного числа коммитов. При этом на ресурсе зарегистрировано около 3% от общего числа интернет-пользователей в РФ, что является довольно высоким значением.

    Сравнительная таблица топ-10 стран по проценту коммитов от общего числа коммитов на 2012 и 2013 годы:

    2012 2013
    Страна Процент коммитов от общего числа коммитов Страна Процент коммитов от общего числа коммитов
    1 США 38,6 США 35
    2 Великобритания 6,3 Великобритания 7
    3 Германия 6 Германия 6
    4 Канада 4 Китай 5
    5 Япония 3,8 Франция 4,5
    6 Китай 3,6 Канада 4,2
    7 Франция 2,7 Япония 4
    8 Нидерланды 2 Россия 3,5
    9 Бразилия 1,9 Бразилия 3
    10 Россия 1,8 Австралия 2,5

    На карте указан прирост процента коммитов от пользователей стран из топ-10. Отмечаем, что у США — отрицательный прирост.

    Топ-10 стран по проценту зарегистрированных на GitHub пользователей от общего числа интернет-пользователей данной страны на 2013 год

    Страна Процент пользователей GitHub от общего числа интернет-пользователей данной страны
    1 США 31
    2 Великобритания 6,5
    3 Китай 6
    4 Германия 5
    5 Франция 4,5
    6 Бразилия 4
    7 Канада 3,5
    8 Индия 3,3
    9 Россия 3
    10 Япония 2,5

    На 2014 год ситуация такова, что из около 1 050 000 активных пользователей, указавших место жительства (из общего количества в 3 955 191 пользователей), россияне составляют 1,5% (16 319 активных пользователей), при этом среди наиболее квалифицированной доли пользователей (критерий квалификации – наличие более 10 последователей) доля россиян составляет 0,91% (в абсолютных числах – 719 из 78 470)

    Сравнительная таблица топ-10 стран по количеству активных пользователей и количеству активных высококвалифицированных пользователей:

    Количество активных пользователей по странам в общем (из 1050000 человек) Количество активных высококвалифицированных пользователей по странам (из 78470 человек)
    Страна Количество пользователей Страна Количество пользователей
    1 США 176910 США 14675
    2 Великобритания 34628 Великобритания 2659
    3 Китай 32009 Китай 2548
    4 Германия 28341 Германия 2226
    5 Индия 25761 Япония 1708
    6 Франция 18549 Франция 1257
    7 Канада 16539 Бразилия 1160
    8 Россия 16319 Канада 1068
    9 Япония 16020 Австралия 977
    10 Австралия 14565 Россия 719

    На карте указано процентное соотношение количества активных высококвалифицированных пользователей к количеству активных пользователей данной страны. Отмечаем, что этот процент больше всего у Японии. Чуть меньше у США и Бразилии, а самый низкий — у Индии. Видать, не зря ходят байки про индусских чудо-программистов

    Выводы

    Кто виноват?

    1. Удельный вес влиятельных IT-специалистов из России (проживающих в России) в мировом IT-сообществе стабильно составляет около 1%.

    2. Удельный вес россиян (проживающих в России), интересующихся IT-сферой (включая влиятельных специалистов), в мировом IT-сообществе составляет около 1,5%, ими производится около 2-3% всего контента.

    3. Незнание или недостаточное знание английского языка может являться серьезным барьером для увеличения степени присутствия российских IT-специалистов на мировой арене. Этот вывод можно сделать на основе того, что доля зарегистрированных пользователей из России на Stackoverflow, где знание английского языка хотя бы на среднем уровне (B1-B2) совершенно необходимо, составляет менее 0.5%. При этом доля зарегистрированных русских пользователей на GitHub, где знание английского необходимо только на начальном уровне (A0-A2), составляет около 1.5%.

    4. Хотя пользователи из России и входят в топ-10 данных ресурсов по абсолютным показателям, по относительным показателям (таким как, например, количество пользователей на 100 000 населения или количество коммитов на 100 000 населения) отстаёт от других стран. Например, (данные на 2012 год) количество коммитов на GitHub на 100 000 человек населения для России – 88 (для сравнения Украина – 143, Беларусь – 247, Эстония – 697, Швейцария — 1437).

    5. В процессе довольно жаркого обсуждения данного отчета на хабре были высказаны еще идеи, почему же русских так мало на StackOverflow и GitHub:

    • — Менталитет, который не позволяет понять, зачем бесплатно делиться чем-то, что было сделано твоим трудом, на что было потрачено время. Грубо говоря — жадность.
    • — Низкий уровень информационной освещенности мировых ресурсов в чудесной стране России
    • — Низкий уровень образования в России и связанная с этим деградация инженерной культуры

    И что же делать?

    В процессе того же жаркого обсуждения на том же хабре были выдвинуты такие идеи:

    1. Создавать больше open-source проектов на русском, которые привлекли бы внимание не только российского IT-сообщества
    2. Донести до российских вузов важность open-source решений и привлекать их к участию в мировом IT-сообществе
    3. Таки учить английский язык хотя бы до уровня A2-B1 и не стесняться применять полученные знания на практике — не бояться ошибаться
    4. Повышать уровень образования в технических вузах, создавать больше курсов повышения квалификации в сфере IT. В общем — поднимать грамотность населения в сфере современных технологий.

    Очень простые и очевидные выводы, конечно. Но вот воплотить их в жизнь — вполне себе нетривиальное дело.

    Пользоваться данными этого отчета можно свободно, убедительная просьба только давать ссылку на этот ресурс. Ну и комментарии (почти) любого содержания приветствуются ��

    Использованные материалы

    Тем, кто интересуется какой-то статистикой, связанной со StackOverflow, я настоятельно рекомендую воспользоваться вот этими сервисами:

    11,982 просмотров всего, 5 просмотров сегодня

    Добавить комментарий