➕增加 服务架构演进

SUMMARY.md

@@ -107,6 +107,7 @@
     - [软件架构](./软件工程/架构/软件架构.md)
     - [实现细节](./软件工程/架构/实现细节.md)
     - [网站架构演进](./软件工程/架构/网站架构演进.md)
+    - [服务架构演进](./软件工程/架构/服务架构演进.md)
     - [前后端分离](./软件工程/架构/前后端分离.md)
     - [前端工程化](./软件工程/架构/前端工程化.md)
     - [架构模式](./软件工程/架构模式/架构模式.md)

软件工程/架构/服务架构演进.md

@@ -0,0 +1,70 @@
+# 服务架构演进
+
+> **Unix的分布式设计哲学**
+> 保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。
+
+## 原始分布式时代
+
+上世纪7 80年代 当时计算机硬件局促的运算处理能力，已直接妨碍到了在单台计算机上信息系统软件能够达到的最大规模。为突破硬件算力的限制，各个高校、研究机构、软硬件厂商开始分头探索，寻找使用多台计算机共同协作来支撑同一套软件系统运行的可行方案
+
+这个时代提出了RPC的雏形以及日后分布式文系统的最早实现AFS
+
+“调用远程方法”与“调用本地方法”尽管只是两字之差，但若要同时兼顾到简单、透明、性能、正确、鲁棒、一致的话，两者的复杂度就完全不可同日而语
+
+**某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果**
+
+这个时间段过后的一端时间 摩尔定律的黄金时代 计算机的算力不断提升 在日后的一端时间 单体软件架构还是主流
+
+## 单体系统时代
+
+在微服务盛行的这段日子 单体系统好像总是以反派身份登场 但对于小型系统 不论是开发 测试 部署，单体系统都有着不可比拟的优越性
+
+乍一看单体架构的缺点似乎会是不可拆分 难以扩展 无法继续支撑越来越大的软件规模
+
+但几乎所有的单体系统都会进行分层拆分：
+
+![202011813502](/assets/202011813502.png)
+
+单体系统的缺陷在于拆分之后的隔离与自治能力上的欠缺，所有的代码都会运行在同一进程空间之内
+
+一旦发生问题 问题就会扩散到整个系统，并且如果想要发布新版本 维护也是一个难题
+
+**为了允许程序出错，为了获得隔离、自治的能力，为了可以技术异构等目标，是继为了性能与算力之后，让程序再次选择分布式的理由**
+
+## SOA时代
+
+- 烟囱式架构：指的是一种完全不与其他相关信息系统进行互操作或者说协调工作的设计模式
+- 微内核架构：也被称为插件式架构，将公共服务、数据、资源集中到一块，成为一个被所有业务系统共同依赖的核心，具体的业务系统以插件模块（Plug-in Modules）的形式存在
+
+![2020118135845](/assets/2020118135845.png)
+
+- 事件驱动架构：通过一个事件管道，各个自系统通过发送/接收事件的方式进行交互
+
+![202011814010](/assets/202011814010.png)
+
+SOA的终极目标是希望总结出一套自上而下的软件研发方法论，所以SOA本身有着许多规范，但正是由于过于严格的规范定义带来过度的复杂性
+
+## 微服务时代
+
+> 轻量级 围绕业务 异构 自动化
+
+在微服务的早期 它还是被作为SOA的一种补充手段
+
+微服务追求的是更加自由的架构风格，摒弃了几乎所有SOA里可以抛弃的约束和规定
+
+## 后微服务时代
+
+>从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代
+
+这里的硬件指的更多是诸如容器 虚拟化技术等为主的基础设施
+
+为了解决在硬件上的服务治理粒度过粗的问题，这个时代完成了第二次进化，也就是服务网格的引入，到目前为止，服务网格还算是个新概念，仍然还在发展
+
+## 另外一条路-无服务时代
+
+>如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点
+
+- 后端设施：指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，称其为后端即服务
+- 函数：指的业务逻辑代码
+
+无服务的无状态特征天生就不适合做某些事，或许在某些场景下，它会做的更好，但长期来看，还是为以服务架构为主