마이크로 채널 대중 번호로 더 흥미로운 기사, 환영주의를 읽기 : 심야 드라이브 고릴라
사이트 아키텍처 개발 프로세스
사이트 아키텍처에 대해 얘기이 문서는 더 배포 아키텍처의 사이트입니다. 아키텍처 응용 프로그램 서비스는 너무 많은 참여와 같은 SOA, 마이크로 서비스로되지 않습니다하십시오.
본 논문은 가상의 이야기를 기반으로합니다, 힘의 사용은 당신이 사이트 아키텍처의 진화 과정을 이해와 대화하는 가장 쉬운 언어를 촬영합니다.
이야기는 시작된다
샤오 우 자신의 자존심 물건이 가치 만들기 위해 기술을 사용하기 위해 자신의 노력에 의해 결정되는 프로그래머입니다.
갑자기 어느 날 샤오 우 이동해야하지만, 가족이 무거운 책을 많이 쌓여, 대부분의 책은 더 이상 사용되지 않지만 잃고 싶지 않아, 정말 멀리 일부를주고 싶다. 그래서, 샤오 우 모두가 사용하는이 같은 웹 사이트를 구축하기 위해 자신의 생각합니다.
무대
샤오 우 그것은 그들의 가장 독창적 인 생각을 코드로 구현을 IT, 주말을했다. 그리고 줄 것. 샤오 우 프로그래머이지만,하지만 또한 제품 개발의 진실 MVP를 이해합니다. 웹 사이트 개발 돼 어떤 사람들은 결과를 확인하는 데 사용할 찾을 수 있습니다. 샤오 우, 자신의 아이디어의 가장 낮은 비용을 확인하기 위해, 알리 구름, MySQL 데이터베이스 서버, Nginx와 정적 리소스 서버, 이상 Tomcat 응용 프로그램 서비스에 배포 Tomcat 응용 프로그램 서버를 설정 아주 싼 클라우드 서버를 구입 이러한 방식으로, 사이트 v0.0.1에 라인.
이제, 샤오 우의 사이트 아키텍처가 표시됩니다 :
그런 다음, 샤오 우 삼십 오 사이트를 사용하는 좋은 친구가 읽고 싶은 발견했다. 사용의 몇 일 후, 친구 및 웹 사이트 경험은 사이트의 가치를 긍정뿐만 아니라 관찰과 권고의 번호를했다. 샤오 우은에 따라, 이러한 요구를 수집 빗질 된 분석 프레임 워크가 필요합니다 "- - 수요 사용자 장면", 그리고 우선 순위. 마지막으로, 우리는 요구 사항을 코딩 새로운 여행을 시작했다.
무대 두
노력의 일주일 후, v0.0.2 버전 샤오 우뿐만 아니라 라인에, 좋은 사이트를 개발했다. 이번에는 샤오 몇 친구의 사용에 만족하지 명나라, 그래서 그는 종종 자신의 사이트에 노출 할 수있는 방법을 찾아 친구들이 사이트를 사용하는 읽기 좋아 소개하는 친구에게, 버블 지역 사회의 다양한 읽어 보시기 바랍니다. 노력, 천 이상 샤오 우의 사이트 사용자의 한 달 후. 웹 사이트의 사용자 경험을 선물로 사용자의 책을 만날 수있는 사이트, 좋은이기 때문에, 온라인 수요는 책의 친구가 될 것입니다 사용자가 자주 사용하는 귀하의 사이트에 더 많은 친구, 더 많은 트래픽의 사용을 권장합니다.
但是，用户的访问速度逐渐下降。小吴收到用户反馈后，网站的日访问量在几万～几十万，应用服务器的内存占用、CPU占较高，特别是本地磁盘I/O操作。可以得出，现在最主要的矛盾就是对数据库的访问降低了整个系统的响应速度。于是，小吴就决定把数据库服务独立出去部署在另外一台服务器，文件存储服务也独立出去。小吴购买了云MySQL服务器、云对象存储OSS，经过两天的努力，小明完成了开发任务和云服务的配置和部署。这样，小吴的网站v0.0.3上线了。
现在，小吴的网站架构如图：
v0.0.3上线后，网站的访问速度恢复正常了。
阶段三
小吴的网站具有自传播效应，加上小吴的持续努力引流，网站的用户越来越多，终于过万了，网站的日访问量十几万～七八十万。但是，网站的访问速度又下降了。小吴又得开始分析问题了。是单台应用服务器不够承担压力？部署多台试试看或者提升服务器的物理配置？但是，这些真的就可以解决网站访问速度慢的问题吗？可以多大程度上提升访问速度？数据库的访问压力怎么样？这时，小明头大了，因为有太多可能的选择了，但是哪一个在现阶段是更优的呢？
直觉告诉小吴，如果应用服务器负载太大，那么数据库服务器负载也同样会大，经过应用服务器的请求都会落在数据库服务器。现在用户在网站上的行为主要是浏览数据，产生数据只是少数用户。于是，小吴尝试给数据的访问加一层缓存试试看。但问题来了，缓存是加在哪儿呢？应用服务器本地内存？还是远程缓存服务器？
小吴想到，如果通过加缓存还解决不了问题的话，需要对应用服务器进行集群部署，这样如果数据直接缓存在本地应用服务器，以后在集群部署的时候会出现数据一致性问题。所以决定对经常被使用但不会改变的数据可以缓存在本地服务器，对于短期内不会修改但是后续会修改又经常被使用的数据缓存在远程服务器。于是，小吴又开始吧啦吧啦写代码实现了缓存这一需求。购置了远程缓存服务器后，小吴的网站v0.0.4上线了。
现在，小吴的网站架构如图：
新版本上线后，网站访问速度恢复正常了。验证了小吴的判断是正确的了
阶段四
随着用户越来越多，网站的访问速度又下降了。这时候，小吴又开始了冷静的分析：在数据访问层加上了缓存，应该不会是数据访问这一环节出现的瓶颈。访问速度下降的瓶颈很可能出现在应用服务器这一层。小吴查看了应用服务器的CPU和内存使用情况，发现大部分时间应用服务器的CPU使用率高达80%，内存占用率一直巨高不下。很明显，应用服务器单点部署已经是网站系统性能的瓶颈了。办法很简单，小吴采用集群部署应用服务的方式来解决。
经过两天的捣鼓调整，小明网站的架构如图：
在应用服务器前面加上来一层负载均衡调度器，通过负载均衡算法分发用户请求到不同的应用服务器集群节点上面。经过调整，网站的访问速度又恢复正常了，甚至比之前的更快了。哈哈，又解决了一次难题～～小吴会心一笑！！
其实，这个架构存在负载均衡调度器单点问题，解决方法是负载均衡调度器主备部署，主节点宕机，备节点接替主节点工作。
阶段五
经过阶段四的努力，小吴的网站扛住了半年的用户增长压力。随着用户越来越多，网站的数据也越来越大。又半年过去了，小吴的网站访问速度又变慢了。小吴尝试通过加应用服务器集群节点，但没有什么改善。很明显，这次是在数据访问层面出现瓶颈了。随着用户数据量越来越多，缓存服务器缓存的数据对于用户访问的数据的覆盖率越来越低了，较多请求直接落在了MySQL数据库上面。小吴识别到了现阶段主要矛盾是数据库的访问，于是小吴在提升数据库服务器性能和数据库读写分离的选择下，选择了数据库读写分离。因为通过更加廉价的物理服务器的水平扩展会比提升物理服务器性能的纵向扩展要更加低成本。这阶段，小吴也对缓存服务器作了主从。如果缓存服务器宕机，所有的请求直接落在数据库上面，这会瞬间降低网站的访问速度的。又经过一番努力，小吴改造好了网站架构并上线。
现在，小吴的网站的架构如图：
到这里，网站已经具备大型网站系统架构雏形了。在上面的五个阶段的架构中，只是介绍了大致的系统架构，但是比如，服务高可用、高性能、数据安全等一些细节不会深入讲解。本文目标是用大白话让大家对网站系统架构演进历程有个理解。其实，对于服务高可用、数据可用性等这些问题，我们基于现有的架构做一些更细节的优化就可以了。比如阶段二如何保持数据可用性，其实在数据库可以进行主备配置，主库进行数据的读写，备库只进行从主库同步数据，。在主库宕机后，备库接替主库进行数据的读写。
阶段六
经过阶段五的优化后，小吴的网站访问速度有了质的提高。网站用户继续增长，数据也越来越多。期间小吴通过添加集群节点方式保持了网站的响应速度。
但是，随着网站的版本迭代，前端页面越来越多，需要加载的东西也越来越多。有些请求，在很长一段时间内返回内容是不变的。这样，一年又过去了。小吴的网站的访问速度又出现变慢的趋势了，小吴通过继续添加应用服务集群节点的方式改善效果不明显，可见，瓶颈出现在数据库层面和静态资源的访问。但是，目前所有的业务数据表都在同一个数据库中。现阶段可以进行数据库的拆分和应用服务的拆分，按照业务维度进行拆分服务和数据库。这样就可以不同业务的数据库使用不同的数据库服务器，可以使用多台服务器分担数据库读写压力，同时应用服务拆分处理可以在不同的集群部署，也分担了更多的请求压力。但是，如果这么做，开发成本和服务器成本较高。
再经过一番分析，小吴了解到主要是前端页面很多请求耗费了一些响应时间，同时一些静态文件没有做好缓存。于是，这次小吴觉得添加CDN和缓存代理服务器。CDN主要是对前端页面静态文件的加速处理，缓存代理服务器主要是缓存一些请求响应的数据。经过一番努力，网站架构改造完成，又上线了网站。
现阶段，小吴的网站架构如图：
结束语
사이트 아키텍처의 6 단계에서 더 발전한다면, 우리는 마이크로 서비스 아키텍처 있다고 생각합니다. 분할 서비스로, 더 클러스터 노드에 배치 핵심 서비스가 서비스에 덜 접근이 적은 저렴 서버 배포를 사용할 수 있습니다,이 서버 자원 활용, 비용 절감을 향상시킵니다. 데이터베이스가 다른 서버에 분산 있도록 동시에 다른 서비스에서, 분산 데이터베이스 액세스 요청을 다른 데이터베이스에 액세스 할 수 있습니다.
여섯 번째 단계 중 하나는 사이트 아키텍처의 진화 과정을 단계로. 물론, 자세한 내용은 데이터베이스 선택, 버퍼 선택으로 고려되지 않습니다. 물론, 거기에 대해 이야기하기 위해 더 많은 수 있지만이 문서의 목적은 모든 사람들이에 사이트 아키텍처 개발 프로세스의 이해를 가질 수 있도록하는 것입니다 수 있습니다, 우리는 뭔가를 사이트의 진화와 아키텍처에 대한 자세한 설명을 계속 제공되지 않습니다.
읽어 주셔서 감사합니다, 경험의 코멘트 섹션을 작성하는 환영 읽은 후이 문서의 단점으로 지적했다.
자원
- 리튬 Zhihui "대규모 웹 사이트 기술 프레임 워크 : 핵심 원칙 및 사례 분석."
마이크로 채널 대중 번호로 더 흥미로운 기사, 환영주의를 읽기 : 심야 드라이브 고릴라