目录1.前言2.架构演进1.单体架构2.应用与数据库分离3.使用缓存抵抗4.多应用部署与Nginx反向代理5.数据库读取写入分离6.应用分组部署7.应用分库设计8.RPC分布式部署9.应用细分与网关介绍10.低代码编程与复用3.架构图??下载4.总结5.系列推荐1.前言architecture，是说开发的框架吗？对于刚接触编程的新人来说，有可能也可以清楚地知道架构是怎么来的，它包括什么。如果非要说架构的话，那可能是IDEA中当前打开的项目就是架构。先不说技术圈里的结构，盖房子的图纸是结构，做豆腐的步骤是结构，结婚的过程是结构吗？执行并输出，那么架构就可以看作是完成目标结果的指导性蓝图。现在在技术架构层面，架构不仅仅是我们研发人员使用的技术框架，还需要根据场景、规模，设置技术选型、实现标准、部署架构，全面完成交付一个专案。应用场景：你的应用场景首先决定你采用哪种架构，这可能包括：电商、贸易、社交、视频、音乐、旅游、外卖等。当然，除了应用场景中的互联网，也会有一些基于物联网的应用，比如：PLC应用，IO板，中继器编码，还有大家熟悉的自提柜。业务规模：这决定了你的用户范围和规模。如果你现在开发一个城市抖音，从上线开始你的用户量会特别大，但是如果你还是一个小型的电商创业团队，那么每天的QPS是维持的在5-10。或许你现阶段并不需要能够承载大量体量的系统架构。这也类似于网络上的一个笑话。球队在建队之初就招了个大boss，就是超级建筑的搭建。系统还没开发出来，公司就没了！考虑的内容是整个技术实现层面的内容。服务类型可能是整个团队对系统拆分模块以及如何支撑的初步考虑。通过业务分层，可以划分，各个团队可以协调支持开发。当然，如果是小团队，最好减少这个环节。即使所有的功能都开发成一个系统，首先要快速验证市场也是很重要的。部署结构：部署结构决定了开发模式，如单体部署、集群部署、分布式部署、云环境等，这将决定技术的选择和框架的结构。例如，如果不使用RPC，就很难实现分布式部署。如果不使用分库分表和大数据环境，就很难支撑分布式部署下的数据应用。开发框架：MVC、DDD，这应该是开发者最先接触到的整个系统架构中的代码开发部分，即具体功能的具体实现层。如果是单体应用，那么一个基本的MVC结构就够了，但是如果是大规模的分布式部署，那么你的系统开发可能有的是用来操作数据库的，有的是专门做业务的，有的是用来做业务的。支持分布式任务，消费MQ消息。技术选型：其实开发框架是MVC还是DDD，并不影响技术选型。任何语言都可以在同一个架构框架下开发。比如你说Java、PHP、GO，只不过他们都有自己的语言，有自己的解决方案。综上所述，是我们研发人员在做架构设计时应该考虑的核心内容。随着我们技术的不断迭代，会有更多更新的想法，就像20年、21年流行的low-code一样，都是为了更好的执行实施方案，降低架构的成本，提高效率。但是如果你想了解和学习架构，最好从它还是小树苗的时候开始，看它是如何一点一点长大的。心中有了这样的架构体系，也能让大家更好的理解和设计自己需要的架构。二、架构演变1、单体架构规模：技术：tomcat、weblogic、Java、Mysql、MVC说明：我的博客bugstack.cn基本就是这个架构，只是开发语言不是Java。这种结构适用于小规模的商业场景，在互联网早期通常是大佬们开发的网站。不过，这种模式现在还没有过时，它还有它的应用场景。2、应用与数据库分离：技术：tomcat、weblogic、Java、DB2、MVC说明：现阶段分离其实变化不大，主要是原来单一架构的应用和数据库一起部署在一台服务器，导致性能不佳。那么最简单高效的拆分就是把应用和数据库分开，让它们在各自的服务器上发挥最大的性能。3、使用缓存阻力分卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis说明：现阶段大家发现我们需要频繁的从数据库中拉取数据，对性能的消耗很大。也尝试将部分数据存储在本地内存中，但是重启服务后这部分数据就没有了。因此，Redis等缓存服务的引入，使得现阶段整体服务的性能有了很大的提升。4、多应用部署和Nginx反向代理卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx说明：当单个服务的容量达到极限时，唯一能想到的就是部署多套，因为这些服务都在做同一件事情，数据库是统一的，所以通过Nginx的反向代理，可以将用户请求分发到不同的服务上，大大减轻了服务压力。5、数据库读写分离卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx说明：数据库读写分离的设计更多是因为一些业务场景需要大量的事务性写入。影响需要读取操作的服务。但是读写分离的设计并没有对系统性能有很大的提升，因为很大程度的读操作已经被Redis抵制了。但是，这种设计思路为后续的架构模型提供了一种新的思路。6、应用组部署卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx说明：所有服务都在一个应用上开发。一个应用所能承载的用户量已经达到了极限，那么下一步最好的架构方式就是将不同的业务拆分到不同的应用中。这些应用程序配备了自己的数据库，并部署在自己的服务器上。这样一来，整体的负载能力就大大提高了。7、应用分库设计量：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat说明：当应用按照不同的业务系统拆分后，下一个瓶颈在于独立应用的数量用户还是很大的，相应的数据库热连接数还在不断增加。因此，在目前的条件下，开始设计应用分库操作，同时分表操作也可能在这个阶段引入。这样一来，单体应用的负载能力得到了很大的提升，但是数据库拆解之后，还需要引入分布式事务、数据聚合等其他技术的使用，来解决新增加的拆解问题。数据库。8、RPC分布式部署卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5说明：系统不断细化后，部分服务不需要持续进行数据库链接操作。它们可能更多的是业务逻辑的包装。同时，这些数据库层操作应用都属于底层系统，所以可以通过这样一个系统来链接数据库操作，通过RPC框架连接上层服务。服务。那么，现在你可以通过分布式部署来提升整体的服务性能。9.应用细分及网关介绍卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、网关、MQ、分布式任务、Elasticsearch说明：从上到下整个过程架构的演进，我们在不断的拆分应用，分离部署，细分应用。我们在不断提升应用服务的能力，让每个应用主体负责独立的事情。在这个阶段，微服务的能力已经开始展现出来。同时，该阶段还介绍了上层网关的统一接入和下层的数据使用能力。10、低代码编程和复用卷：技术：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、网关、MQ、分布式任务、Elasticsearch、SDK、低代码、支持服务描述：现阶段服务框架基本可以很好的支撑用户体量，所以我们开始考虑如何更高效的开发和交付。然后介绍了服务编排、服务治理以及通用模块、组件和中间件。其实这些设计在压缩的时候基本上只是你过去开发的一个应用，但是把所有不属于业务逻辑的通用功能不断的拆分出来，然后通过这些细分的组件和服务能力的排列，提供需要的接口，极大地提高了可持续交付集成的效率。3.架构图下载有朋友反映，看了架构图，也有了一些自己的想法，但是开始画的时候很迷茫，不知道从何下手。那么傅哥就把绘制的架构图原稿分享给大家，有兴趣的朋友可以下载使用。4.小结本章也是福哥整理架构系列内容资料的一个小结，让新人对架构有一个从小到大的认识。在总结的时候，我们也结合现在的结构简化了部分内容，因为只有理解了最重要的内容，才能继续展开枝叶。从演进过程可以看出，业务量会影响部署，部署形式会改变架构，架构会响应开发方式。说到底，语言只是目前最适合某种架构的工具，各种技术栈的使用也是针对技术需求的。并存在。最后，如果你也想让图表达你的意思，那你可以试着画个图，总结一下，找到适合你的图结构来表达结果。
