-
容易适应复杂,混乱的业务环境
-
当出现新的事件类型时,很容易扩展
注意事项:
=====
-
如果模块之间可以相互影响,则[测试可能会很复杂
-
当模块发生故障时,中央单元(或消息中间件)必须有一个事件备份计划。
-
消息传递开销可能会降低处理速度,消息中间件必须缓冲以突发形式到达的消息时。
-
当事件有非常不同的需求时,为事件开发数据结构可能会很复杂。
-
维护基于事务的一致性机制很困难,因为接收事件的模块是解耦和独立的。
适合:
===
-
具有异步数据流的异步系统
-
各个数据块仅与多模块中的少数模块交互的应用程序
-
用户界面
三、微内核-多插件架构
===========
许多的应用程序都具有一组核心代码,这些代码在不同的模块下反复使用。例如,开发工具Eclipse将打开文件,批注,编辑文件并启动后台处理器。用于显示文件和对其进行编辑的代码是微内核的一部分。其他的插件扩展了Eclipse,从而扩展了其功能。
具体到解决方案就是将一些基本的核心的任务代码推入微内核。然后,不同的业务部门可以根据不同类型的声明编写插件。
注意事项:
=====
-
确定哪些代码是微内核中的内容通常是一门艺术。它应该保留经常被使用的代码。
-
一旦许多插件依赖微内核,修改微内核可能非常困难,甚至不可能。唯一的解决方案就是修改插件。
-
为内核函数选择正确的粒度很难事先完成,也几乎不可能在后期进行更改。
适合:
===
-
工具类软件
-
在核心代码与边缘代码之间有清晰区分的应用程序
-
具有一组固定的核心函数和一组动态规则的应用程序
四、微服务架构
=======
小宝宝既可爱又有趣,但是一旦变大,就很难操纵并且难以维护。微服务架构旨在帮助开发人员避免让自己的宝宝长大,笨拙,僵硬,烦人。它的目标不是创建一个大型程序,而是创建多个不同的小型程序。避免修改一个小bug,就需要重新部署整个大型应用的情况出现。
这种方法类似于事件驱动和微内核方法,但是主要用于解耦不同模块及任务。在许多情况下,不同的任务可能需要不同的处理量,并且用途可能会有所不同。所以微服务的特点是便于修改、便于扩展。使用负载均衡及服务发现的机制,在用户使用高峰期部署更多的微服务,保证服务的高可用;在用户低频服务时段缩减微服务,从而节省服务器资源。
注意事项:
=====
-
并非所有应用程序都可以拆分为相对独立的微服务单元。
-
当任务分散在不同的微服务之间时,通信成本会更大。单个请求的响应时长会增加。
适合:
===
-
快速发展新业务团队
-
大型Web应用程序
五、高速缓存架构
========
许多网站都是围绕数据库构建的,只要数据库能够满足负载,它们就可以正常运行。但是当使用量达到顶峰,并且数据库无法跟上用户请求的速度时,整个网站就会瘫痪。将数据存储在内存中可以使许多工作更快,从而大幅度提高用户并发访问的支撑能力。
注意事项:
总结
我们总是喜欢瞻仰大厂的大神们,但实际上大神也不过凡人,与菜鸟程序员相比,也就多花了几分心思,如果你再不努力,差距也只会越来越大。实际上,作为程序员,丰富自己的知识储备,提升自己的知识深度和广度是很有必要的。
Mybatis源码解析
程序员相比,也就多花了几分心思,如果你再不努力,差距也只会越来越大。实际上,作为程序员,丰富自己的知识储备,提升自己的知识深度和广度是很有必要的。
Mybatis源码解析
[外链图片转存中…(img-gn5e8xP9-1714732027216)]
[外链图片转存中…(img-ZiCZbRCa-1714732027217)]