项目架构的演进

目录

• 前言
• 一、单体架构
• 二、前后端分离
• 三、集群和负载均衡
• 四、分布式
• 五、微服务
• 总结

前言

本文基于某锋教育的涛哥的视频，做一下笔记和理解梳理，从一个新手的角度浅谈一下项目架构的演进，过程中偶然发现有大佬讲的更详细的项目架构的演进https://segmentfault.com/a/1190000018626163，本文参考大佬文章，大概思维导图目录如下

一、单体架构

最初的时候，网站的前后端代码部署在同一台服务器上，当用户使用浏览器访问网站时，浏览器先往www.taobao.com发起请求时，首先经过DNS服务器（域名系统）把域名转换为实际IP地址10.102.4.1，浏览器转而访问该IP对应的Tomcat，假设用户请求的是1个html，2个css文件，1个js文件，服务器端tomcat根据业务逻辑接收并处理用户的请求，并返回所需要的html页面，浏览器解析html页面，再次发起请求页面中所需要的css、js、图片等资源文件，服务器端tomcat再次根据业务逻辑接收并处理浏览器的请求，并返回所需资源文件。

ps:自己画的图不怎么滴，之后还是用课上的图吧，这里有很多详细的过程没有说，比如DNS服务器的解析过程、比如浏览器发起请求的过程、比如服务器解析的过程等等，本文主要讨论架构的演进，所以部分略过。当然，如果有理解的不对的地方，也欢迎评论指出，毕竟这个只是我个人粗浅的对视频课程的理解以及对大佬文章的理解。

Tomcat默认支持150并发，最大并发量超过250可能服务就会出现问题参考文章：https://www.cnblogs.com/zhaosq/p/10870762.html
总结：
单体架构的缺点是当同时访问用户过大时，单机性能不足以支撑业务！这个时候不管是静态资源的请求还是业务逻辑的处理压力全落到一台服务器上。与此同时，随着业务的复杂，代码的更新与维护的复杂度和成本与日俱增，不仅如此，还由于耦合度过高，某一个业务的故障可能导致整个服务的停止。

二、前后端分离

基于单体架构的出现的问题，项目架构必须发生改变！解决思路很简单，既然1台服务器无法支撑，那么就用2台服务器来支撑呗。把需要多次请求的静态资源放在足以支撑万级并发的Nginx服务器上，把业务逻辑的处理放在Tocat服务器上。这样实现前后端分离来解决问题。
这时，假设浏览器发来登录请求，nginx服务器根据多次请求返回1js，2css，4imgs等文件，浏览器解析页面以后显示给用户，用户输入密码和账户，再次发起请求，Tomcat服务器进行处理，通过和数据库的交互返回检查结果，浏览器根据返回结果显示给用户结果，是输错密码了，还是账户不存在等等。

总结：前端和后端分离开发和部署（前后端部署在不同的服务器），将对静态资源的访问和对接⼝的访问进⾏分离，Tomcat服务器只负责数据服务的访问，这样可以解决部分单体架构的问题。

ps:涛哥这里省略了部分架构演进过程到后面才说，或者更精确的说是大佬的视角是业务从一百并发到千万级并发演进的过程各种技术直接穿插了进来，而涛哥则是从教学的角度方便学生理解的架构演进的过程。

三、集群和负载均衡

可以看的到的是Tomcat能所能支持最大同时访问用户也就250的样子，这个时候继续1不行上2个，2个不行上3个的思路，在多台服务器上分别部署Tomcat，使用反向代理软件（Nginx）把请求均匀分发到每个Tomcat中来解决问题。每一个tomcat服务器就是一个服务器节点，多台tomact服务器就是一个集群。

四、分布式

这时，数据库的访问业务随着tomcat可处理的并发量增加成为瓶颈。继续一个不行来俩的思路，把数据库的访问业务和业务逻辑处理进行拆分，Tomcat和数据库分别独占服务器资源，两者性能显著提高，但是数据库的性能还是瓶颈的问题并没有解决。于是引入tomcat本地缓存来减轻数据库服务的压力，同时，可以引入mycat分布式数据库进行数据库的读写分离，这时已经基本解决了问题。可是随着业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能。这个时候可以通过数据库按业务进行分库分表来解决问题。对于具体的业务需要有不同的方法，针对热点事件业务的需要可以引入redis集群缓存来解决问题，针对搜索业务检索的需要可以引入ES来解决问题。

对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决
对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。
当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。

ps：大佬的文章中这里讲了第七次和第八次演进主要是随着数据库和tomcat的变强扩展，单机的nginx也就是静态资源的服务器成为总体并发量提高的瓶颈的解决问题，讲的很通俗易懂，但是课程中需要讲解的技术框架不涉及这方面，所以没有。由于个人理解叙述可能词不达意，且可能存在问题，分布式这部分具体建议可以看看大佬文章，这里讲的真的很好！链接再放一下：https://segmentfault.com/a/1190000018626163

五、微服务

引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难。所以把大应用拆分为小应用，并且把可以复用的功能抽离成微服务。如下图所示：

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

ps:到这里基本上应用的开发问题已经基本解决了互联网的高并发、高可用、高性能的问题，接下来要解决的是在服务器上的部署和运维等问题。
解决方案就是引入容器化技术Docker实现运行环境隔离与Kubernetes(K8S)动态服务管理。

总结

项目架构的演变路径有一定了解不仅能够对项目的架构演进有整体的感知和理解，而且对于我们要学习的技术路线其实也是非常好的指引作用！
从最开始的单体架构来说， 学习JavaWeb、SpringBoot+Mybatis、前端等知识搭起一个基础单体服务，到前后端分离拆分，更加深入的理解前面所学知识，为下一步打好基础。

到分布式和微服务，学习各种技术框架，比如Redis等针对不同的业务场景解决互联网的高并发、高可用、高性能的问题。

然后就是学习部署也就是上线交付和运维的问题，学习Docker，k8等来解决问题。

作者水平有限，部分内容可能存在问题，欢迎评论指出，文章最后再次感谢视频作者涛哥和文章作者huashiou
原文链接：https://segmentfault.com/a/1190000018626163