关于软件架构的思考

一个突然的想法引发的不成熟的技术推演

单体应用

	许多软件的诞生应该都是由单体应用演变而来
	而这个过程是许多个名勇士用血的教训得出来的
	最初的ssm+mvc(思想) spring+smvc+mybatis :  mapper >service> controller
	整体看来属于很简单很单纯的技术架构，
	优点都知道 很清晰 一眼看破！
	缺点：1.新手不太友好 ，各种各样的配置文件引起的漏，冲突，这类问题（属于）很好解决的
			2.业务的增加 以及复杂度的增加，工具类的引入 会使		整个架构显得很拥挤虽然架构层次很清晰，但是业务之间的依赖性 会造成引					用循环、耦合度激增 导致很多很烦人的的问题。

当然在此基础上出现了一些改进maven 多模块 我见到的第一个多模块是这样的思想：
common(提供配置、工具类等一些辅助物品) --》data (专门处理业务)–》api 对外开放
各有各的功能各司其职，传递式架构，common提供支持给data data提供业务数据 给 api api 给前端
优点：功能分化明显
缺点：
1.配置文件一样都不能少
2.单体缺陷无法逃脱

springboot

简化配置：

由上面的传统ssm 升级到springboot 简化了大多的配置
缺陷：依然单体
当业务模块达到一定数额后 更新 ，增加 会显得格外麻烦
实际场景：
比如 抖音 我要增加一个新功能时 这个功能上去的时候总不能全部都停吧？高密度的使用时段的时候 重启会引发很多不必要的问题
这时候就需要想办法了 怎样才能增加新功能而不影响其他的功能 重启也能不会使其他模块停掉？
这时候会自然而然地想到独立业务模块，时每个业务模块都是独立系统 他们之间只存在业务上的联系 减少其他方面的联系，相信大家都明白吧？ 咱们就从不会应用只听说过来讲  spirngclude 等微服务框架的出现解决了之一问题，
咱们就初略的思考 微服务就是独立的每个业务模块
新的问题出现了  这些模块之间怎么通信呢？
**中间件闪亮登场:**
		路由技术 -----解决通信
		熔断---解决一些不可预知的问题
		链路追踪--清晰调用顺序问题
		网关---网络安全方面的问题
		日志什么的-会出现一种现在都在搞elk 那个还不懂哈。就是看日志的 好找错误
		简写 
		目前工作 
			一年零3个月 初始springclude 都没看完呢。。看的时候很模糊 ，今天的一次思考让我明白了很多
			中件为什么会出现？ 架构为什么会不断演变？什么时候选什么架构。通过逻辑推演，技术推演，
			可以对一些技术能够有一些预见性，
		上面一些技术架构思想流行的时间顺序有可能也有些误差，请大佬们多多指导 ，这篇文章算是我的简单思考 ，只能写这么多了经验不多。就连上面的中间件的名字都记不全，，只知道一些东西就该出现在那个位置，因为有必然性。晚安！