架构演变

单体架构(spring boot)

优点：所有代码都运行在同一个进程空间之内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失。
缺点：损失了各个功能模块的自治、隔离能力；
由于隔离能力的缺失难以阻断错误传播、不便于动态更新程序以外，还面临难以技术异构的困难
可以使用OSGi 这种运行时模块化框架，但是太复杂了。

面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。

SOAP 协议被逐渐边缘化的本质原因：过于严格的规范定义带来过度的复杂性。而构建在 SOAP 基础之上的 ESB、BPM、SCA、SDO 等诸多上层建筑，进一步加剧了这种复杂性。

微服务是一种软件开发技术，是一种 SOA 的变体形式。

升级背景：

由于隔离能力的缺失，单体除了难以阻断错误传播、不便于动态更新程序以外，还面临难以技术异构的困难，每个模块的代码都通常需要使用一样的程序语言，乃至一样的编程框架去开发。

随着软件架构演进，构筑可靠系统从“追求尽量不出错”，到正视“出错是必然”的观念转变，才是微服务架构得以挑战并逐步开始取代运作了数十年的单体架构的底气所在

微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。

升级背景：

微服务中的各种新技术名词，如配置中心、服务发现、网关、熔断、负载均衡等等带来的技术组件 Config、Eureka、Zuul、Hystrix、Ribbon、Feign 等
占据了产品的大部分编译后的代码容量
之前在应用层面而不是基础设施层面去解决这些分布式问题，完全是因为由硬件构成的基础设施，跟不上由软件构成的应用服务的灵活性的无奈之举
以 Docker Swarm、Apache Mesos 与 Kubernetes 为主要竞争者的“容器战争”终于有了明确的结果，Kubernetes 登基加冕
容器动态构建出 DNS 服务器、服务负载均衡器等一系列虚拟化的基础设施，去代替原有的应用层面的技术组件

升级背景：

基础设施是针对整个容器来管理的，粒度相对粗旷，只能到容器层面，对单个远程服务就很难有效管控。
服务的监控、认证、授权、安全、负载均衡等都有可能面临细化管理的需求
譬如服务调用时的负载均衡，往往需要根据流量特征，调整负载均衡的层次、算法，等等，而 DNS 尽管能实现一定程度的负载均衡，但通常并不能满足这些额外的需求。

数据平面通信：这个代理除了实现正常的服务间通信外（称为数据平面通信）
控制平面通信：还接收来自控制器的指令（称为控制平面通信），根据控制平面中的配置，对数据平面通信的内容进行分析处理，以实现熔断、认证、度量、监控、负载均衡等各种附加功能。
通过
主要框架：Istio

上帝的归上帝，凯撒的归凯撒，业务与技术完全分离，远程与本地完全透明，也许这就是最好的时代了吧？

更应该成为无服务器

包含两方面：

后端设施：指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，无服务中称其为“后端即服务”（Backend as a Service，BaaS）。
函数：指业务逻辑代码，这里函数的概念与粒度，都已经很接近于程序编码角度的函数了，其区别是无服务中的函数运行在云端，不必考虑算力问题，不必考虑容量规划（从技术角度可以不考虑，从计费的角度你的钱包够不够用还是要掂量一下的），无服务中称其为“函数即服务”（Function as a Service，FaaS）。

学习参考https://icyfenix.cn/architecture/architect-history/