《周志明的软件架构课》学习笔记 Day3

1.主动学习

单体架构

防止陷入思维误区「单体架构是落后的系统架构风格，最终会被微服务所取代」其实都有一个没有明说的隐含定语：“大型的单体系统”
所以当我们在讨论单体系统的缺陷的时候，必须基于软件的性能需求超过了单机，软件的开发人员规模明显超过了“2个披萨原则”范畴的前提下，这样才有讨论的价值。

在获得了进程内调用的简单、高效这些好处的同时，也就意味着，如果在单体架构中，有任何一部分的代码出现了缺陷，过度消耗进程空间内的公共资源，那所造成的影响就是全局性的、难以隔离的。

优秀留言
单体架构并不是一无是处，在公司的初始阶段，为了业务的快速上线，必须得采用单体架构，随着业务的增长，架构才得以演进，还是那句话，架构不是一层不变的，是持续演进的，或许，微服务也不是终点。

SOA架构

SOA 演化过程的中间产物架构：烟囱式架构（信息孤岛式系统）、微内核架构（插件式架构）、事件驱动式架构

“面向服务的架构”（Service Oriented Architecture，SOA）
SOA 最根本的目标，就是希望能够总结出一套自上而下的软件研发方法论，让企业只需要跟着它的思路，就能够一揽子解决掉软件开发过程中的全套问题。比如，如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发测试部署新的功能，等等。
但是开发信息系统毕竟不是写八股文，SOA 架构过于严谨精密的流程与理论，导致了软件开发的全过程，都需要有懂得复杂概念的专业人员才能够驾驭。从 SOA 诞生的那一天起，就已经注定了它只能是少数系统的阳春白雪式的精致奢侈品：它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广

备注

摘自极客时间 - 周志明老师的公开课《周志明的软件架构课》 <- 极其推荐大家阅读~>

2. 写在最后

Unix DCE 提出的分布式服务的主旨：让开发人员不必关心服务是远程还是本地，都能够透明地调用服务或者访问资源

从单体到SOA，文章中很多的概念、思想真的很值得借鉴
比如现在流行的低代码平台利用的何尝不是插件式模式