关于java:笔记整理技术架构涵盖内容和演变过程总结

作者：小傅哥
博客：https://bugstack.cn

积淀、分享、成长，让本人和别人都能有所播种！????

一、前言

架构，说的是开发用的框架吗？

对于刚接触编程的新人来说，可能并不能很分明的晓得架构是怎么来的，都包含什么内容。如果非得说什么架构，那么可能就是目前在 IDEA 中关上的工程就是架构。

抛开技术圈内的架构而已，盖房子的图纸算不算架构、做豆腐的步骤算不算架构、结婚的流程算不算架构？演绎得出，所有的这些步骤都在计算成本、耗材、执行和产出，那么架构就可以看做是一个用于实现指标后果的领导蓝图，当初在放到技术架构的层面来看，架构就不只是咱们研发人员用到的技术框架，还须要依据场景、规模，设定技术选型、施行规范、部署构造，综合来实现一个我的项目的交付。

• 利用场景：你的利用场景是最先决定你采纳哪种架构的，这可能会包含：电商、交易、社交、视频、音乐、出行、外卖等等，当然除了互联网中的利用场景，还会有一些基于物联网的利用，例如：PLC 利用、IO 板卡、中继器打码以及你相熟的小区自提柜。
• 业务规模 ：这决定了你的用户范畴和体量，如果你是在当下正火的抖音里开发商城，那你的用户体量基数从上线之初就会特地大，但如果你还是一个初创团队小电商，那么每天的 QPS 维持在 5~10，可能这个阶段你就不须要有能承载多大体量的零碎架构。 这也相似网络上的笑话，团队初期招聘某大厂大佬，上来就是超级架构的建设，没等零碎开发完呢，公司没了！
• 服务类型：有了场景和规模的设定，接下来要思考的内容就是整个技术实现层面的内容，服务类型可能是整个团队最后对系统拆分模块和如何反对的考量，有了业务的分层就能够划分出由各个团队来协同反对开发。当然如果是小团队那么这一环节最好放大，哪怕把所有的性能都开发到一个零碎里去，先疾速验证市场是次要的。
• 部署构造：是部署构造决定了开发模式，单体部署、集群部署、分布式部署、云环境等，这些都会决定技术的选型和框架的构造。例如不援用 RPC，那么就很难实现分布式部署，如果不应用分库分表和大数据环境，也很难撑持起分布式部署下的数据利用。
• 开发框架：MVC、DDD，这应该是研发人员最先接触到整个零碎架构中的代码开发局部，也就是具体性能的具体实现层，如果是单体利用那么根本一个 MVC 构造就够了，但如果是大体量的分布式部署，那么你的零碎开发里可能有的是操作数据库的，有的是专门做业务的，有的是用于反对分布式工作和生产 MQ 音讯的。
• 技术选型：其实开发框架，无论是 MVC 还是 DDD，都是不影响技术选型的，任何一种语言都能够放在同样的架构框架中进行开发，比方你说 Java、PHP、GO，只不过它们都是在本人语言下有本人的解决方案。

综上，就是咱们研发人员在做架构设计时要思考的核心内容，随着咱们技术的一直迭代也会有更多更新的思维，就像 20 年热起来中台、21 年热起来的低代码，都是为了更好的让架构降本增效的实施方案。

但如果想理解和学习架构，最好还是要从它是一颗小树苗时候看起，看看它是如何一点点长大的。在头脑中有了一个这样的架构体系，也能让大家更好的了解和设计你须要的架构。

二、架构演变

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、低代码、撑持服务
• 形容：在目前这个阶段服务框架根本曾经能够很好的撑持用户体量，所以也开始思考如何更高效的开发和交付问题。那么也就引入了服务编排、服务治理以及通用的模块、组件和中间件。而这些设计其实压缩来看根本就是以前你开发的一个利用而已，不过把所有非业务逻辑的通用性性能一直的拆分进去了，再通过这些细分的组件和服务能力的编排，提供所需接口，这样一来也就大大的晋升了可继续交付集成的效率。

三、架构图???? 下载

有小伙伴反馈看了架构图，也有了点本人的想法，然而入手画的时候就很懵，不晓得从哪开始。那么小傅哥把画的架构图原稿分享给大家，能够让感兴趣的小伙伴下载应用。

下载方式

• 公众号：bugstack 虫洞栈，回复：架构图 ，即可取得最新的下载链接。 后续更新和补充会更换链接
• 增加小傅哥微信 (fustack)，备注： 架构图

四、总结

• 本章也是小傅哥在整顿系列架构内容材料的一个总结，让 新人码农 对架构有一个从小到大的意识。在总结整顿时也联合当初的架构简化了一部分内容，因为只有剥丝抽茧的看懂最骨干的内容，大家才好一直的扩大枝叶。
• 从演变的过程咱们能够看到，业务体量会影响部署，部署状态会扭转架构，架构会响应开发方式，最终语言只是以后最合适某种架构的工具，各项技术栈的使用也是为了技术需要而存在。
• 最初，就是如果你也想让图表白出你的意思，那么能够尝试画一画、总结总结，找到一种能适宜你表白出后果的画图构造。

五、系列举荐

• 工作两三年了，整不明确架构图都画啥？
• 技术扫盲：对于低代码编程的可持续性交付设计和剖析
• 方案设计：基于 IDEA 插件开发和字节码插桩技术，实现研发交付品质主动剖析
• 半年招聘筛选了 400+ 份简历，通知你怎么写容易被撩！
• 《Java 面经手册》PDF，全书 417 页 11.5 万字，完稿 & 发版！