作为一名Java程序员，对系统架构的演变还是需要清楚的，首先就简述一下架构的演变历程
1、单体架构（集中式架构）
单体架构比较初级，典型的三级架构，前端(Web/手机端) + 中间业务逻辑层 + 数据库层。这是一种典型的Java Spring MVC 框架的应用
单体架构就是把所有的功能、模块都集中到一个项目中，部署在一台服务器上，从而对外提供服务（集中式架构、单体服务、单体应用）
单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
2、分布式架构
在《分布式系统原理与范型》一书中有如下定义：分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。
简单来说，就是将所有的功能、模块拆分成不同的子项目，部署在多台不同的服务器上，这些子项目相互协作共同对外提供服务
该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。如一个电商项目可以拆分成 用户user，订单order，购物车shop等子项目\模块
该图片来自百度
该架构优点：
（1）降低了耦合度：把模块拆分，使用接口通信，降低模块之间的耦合度
（2）责任清晰：把项目拆分成若干个子项目/模块，不同的团队负责不同的子项目/模块
（3）扩展方便：增加功能时只需要再增加一个子项目/模块，调用其他系统的接口即可
（4）部署方便:可以灵活的进行分布式部署
（5）提高代码的复用性：如service层，如果不采用分布式服务架构，就需要在pc，android，ios端都写一个service层，开发量大难以维护升级，采用分布式服务，共用一个service层
缺点 ：系统之间的交互要使用远程通信，接口开发增大工作量（但总体优点大于缺点）
3、微服务架构
下面着重梳理
4、云原生架构
云原生应用一般是指原生支持云部署，并能充分利用和发挥云平台能力的应用程序。它一般有3大特征：
容器化封装。容器化封装是指以容器为基础，应用程序封装在容器之中，在容器里运行，实现资源的相对隔离与容器镜像的重复使用。
面向微服务。面向微服务是指把一个大的功能应用拆分成一个个功能单一、相对独立、相互解耦的微应用，微应用之间通过接口进行通讯。
动态管理。动态管理指通过一个统一的编排工具，比如K8S，来动态的管理和调度这些微服务。
后来随着云计算的发展，CNCF云原生计算基金会又增加了另外2条：声明式的API、服务网格。
如果某个应用符合以上的几点特征，就可以称为云原生应用。因为云原生应用天生的各种优势，越来越多的企业开始拥抱云原生，这就要求企业有一个新的技术架构使之能更好的利用云原生技术。而这种利用云原生技术让业务更敏捷、成本更低、应用更强的技术架构，就可以成为云原生架构。它利用容器技术，基于微服务，借助敏捷方法，通过DevOps路程来实现应用的持续交付。
云原生架构 = 微服务 + 容器化 + DevOps + 持续交付。
一、微服务架构（Microservice Architecture）
微服务架构（Microservice Architecture）
微服务（Microservices）是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
微服务起源由来
“微服务”这个技术名词最早在2005年就已经被提出，它是由Peter Rodgers博士在2005年度的云计算博览会（Web Services Edge 2005）上首次使用，当时的说法是“Micro-Web-Service”，指的是一种专注于单一职责的、语言无关的、细粒度Web服务（Granular Web Services）。
Microservices
微服务真正的崛起是在2014年，也是从Martin Fowler（马丁.福勒）与James Lewis（詹姆斯·刘易斯）合写的文章《Microservices: A Definition of This New Architectural Term》中首次了解到微服务的。大家所了解的“微服务”是这篇文章中定义的“微服务”
原文连接 Microservices
翻译原文连接 微服务｜YYGCui's blog
在此文中，首先给出了现代微服务的概念：
“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。”
此外，文中列举了微服务的九个核心的业务与技术特征，下面将其一一列出并解读。
- 围绕业务能力构建（Organized around Business Capability）。这里再次强调了康威定律的重要性，有怎样结构、规模、能力的团队，就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合，而是必然的演化结果。如果本应该归属同一个产品内的功能被划分在不同团队中，必然会产生大量的跨团队沟通协作，跨越团队边界无论在管理、沟通、工作安排上都有更高昂的成本，高效的团队自然会针对其进行改进，当团队、产品磨合调节稳定之后，团队与产品就会拥有一致的结构。
- 分散治理（Decentralized Governance）。这是要表达“谁家孩子谁来管”的意思，服务对应的开发团队有直接对服务运行质量负责的责任，也应该有着不受外界干预地掌控服务各个方面的权力，譬如选择与其他服务异构的技术来实现自己的服务。这一点在真正实践时多少存有宽松的处理余地，大多数公司都不会在某一个服务使用Java，另一个用Python，下一个用Golang，而是通常会有统一的主流语言，乃至统一的技术栈或专有的技术平台。微服务不提倡也并不反对这种“统一”，只要负责提供和维护基础技术栈的团队，有被各方依赖的觉悟，要有“经常被凌晨3点的闹钟吵醒”的心理准备就好。微服务更加强调的是确实有必要技术异构时，应能够有选择“不统一”的权利，譬如不应该强迫Node.js去开发报表页面，要做人工智能训练模型时，应该可以选择Python，等等。
- 通过服务来实现独立自治的组件（Componentization via Services）。之所以强调通过“服务”（Service）而不是“类库”（Library）来构建组件，是因为类库在编译期静态链接到程序中，通过本地调用来提供功能，而服务是进程外组件，通过远程调用来提供功能。前面的文章里我们已经分析过，尽管远程服务有更高昂的调用成本，但这是为组件带来隔离与自治能力的必要代价。
- 产品化思维（Products not Projects）。避免把软件研发视作要去完成某种功能，而是视作一种持续改进、提升的过程。譬如，不应该把运维只看作运维团队的事，把开发只看作开发团队的事，团队应该为软件产品的整个生命周期负责，开发者不仅应该知道软件如何开发，还应该知道它如何运作，用户如何反馈，乃至售后支持工作是怎样进行的。注意，这里服务的用户不一定是最终用户，也可能是消费这个服务的另外一个服务。以前在单体架构下，程序的规模决定了无法让全部人员都关注完整的产品，组织中会有开发、运维、支持等细致的分工的成员，各人只关注于自己的一块工作，但在微服务下，要求开发团队中每个人都具有产品化思维，关心整个产品的全部方面是具有可行性的。
- 数据去中心化（Decentralized Data Management）。微服务明确地提倡数据应该按领域分散管理、更新、维护、存储，在单体服务中，一个系统的各个功能模块通常会使用同一个数据库，诚然中心化的存储天生就更容易避免一致性问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。譬如，Bookstore应用中的书本，在销售领域中关注的是价格，在仓储领域中关注的库存数量，在商品展示领域中关注的是书籍的介绍信息，如果作为中心化的存储，所有领域都必须修改和映射到同一个实体之中，这便使得不同的服务很可能会互相产生影响而丧失掉独立性。尽管在分布式中要处理好一致性的问题也相当困难，很多时候都没法使用传统的事务处理来保证，但是两害相权取其轻，有一些必要的代价仍是值得付出的。
- 强终端弱管道（Smart Endpoint and Dumb Pipe）。弱管道（Dumb Pipe）几乎算是直接指名道姓地反对SOAP和ESB的那一堆复杂的通信机制。ESB可以处理消息的编码加工、业务规则转换等；BPM可以集中编排企业业务服务；SOAP有几十个WS-*协议族在处理事务、一致性、认证授权等一系列工作，这些构筑在通信管道上的功能也许对某个系统中的某一部分服务是有必要的，但对于另外更多的服务则是强加进来的负担。如果服务需要上面的额外通信能力，就应该在服务自己的Endpoint上解决，而不是在通信管道上一揽子处理。微服务提倡类似于经典UNIX过滤器那样简单直接的通信方式，RESTful风格的通信在微服务中会是更加合适的选择。
- 容错性设计（Design for Failure）。不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实，要求在微服务的设计中，有自动的机制对其依赖的服务能够进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。所以“断路器”这类设施，对实际生产环境的微服务来说并不是可选的外围组件，而是一个必须的支撑点，如果没有容错性的设计，系统很容易就会被因为一两个服务的崩溃所带来的雪崩效应淹没。可靠系统完全可能由会出错的服务组成，这是微服务最大的价值所在，也是这部开源文档标题“The Fenix Project”的含义。
- 演进式设计（Evolutionary Design）。容错性设计承认服务会出错，演进式设计则是承认服务会被报废淘汰。一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生。假如系统中出现不可更改、无可替代的服务，这并不能说明这个服务是多么的优秀、多么的重要，反而是一种系统设计上脆弱的表现，微服务所追求的独立、自治，也是反对这种脆弱性的表现。
- 基础设施自动化（Infrastructure Automation）。基础设施自动化，如CI/CD的长足发展，显著减少了构建、发布、运维工作的复杂性。由于微服务下运维的对象比起单体架构要有数量级的增长，使用微服务的团队更加依赖于基础设施的自动化，人工是很难支撑成百上千乃至成千上万级别的服务的。
微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过rpc来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期
分布式服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的
分布式系统各个模块通过接口进行数据交互，其实分布式也是一种微服务，因为都是把模块拆分变为独立的单元，提供接口来调用
因此，我们会发现分布式和微服务之间有很多相似之处，但是又不完全相同。他们之间还是有一些区别
1、微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化
2、微服务和分布式本质区别
微服务和分布式结构的本质的区别体现在“目标”上
微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，也可以是同一个服务器。
分布式属于微服务，将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
分布式和微服的架构很相似，只是部署的方式不一样而已。
分布式架构就是为了解决：用户访问量很大一台机器承受不了，或者是成本问题，不得不使用多台机器来完成服务的部署
微服务结构设计是为了不因为某个模块的升级和BUG影响现有的系统业务；只是让各个模块拆分开来，不会被互相影响，如模块的升级或者出现BUG或者是重构等等都不要影响到其他模块，微服务它是可以在一台机器上部署
微服务重在解耦合，使每个模块都独立。分布式重在资源共享与加快计算机计算速度
分布式也是微服务的一种，微服务也属于分布式
二、SpringCloud
微服务是一种项目的架构方式、架构理念； 那么Spring Cloud便是对这种架构方式的技术实现
SpringCLoud官网：Spring Cloud
下文引自官网
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
Features
Spring Cloud focuses on providing good out of box experience for typical use cases and extensibility mechanism to cover others.
Distributed/versioned configuration
Service registration and discovery
Routing
Service-to-service calls
Load balancing
Circuit Breakers
Global locks
Leadership election and cluster state
Distributed messaging
翻译如下：
Spring Cloud为开发人员提供了一些工具用来快速构建分布式系统中的一些常见模式和解决一些常见问题（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、群集状态）。分布式系统的协调导致了很多样板式的代码（很多固定套路的代码），使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地运行，包括开发人员自己的笔记本电脑、裸机数据中心和云计算等托管平台；
Spring Cloud特性
Spring Cloud为分布式系统开发的典型应用场景提供良好的开箱即用的功能，比如：
分布式/版本化配置
服务注册和发现
路由
服务与服务间的调用
负载均衡
断路器
全局锁
领导选举与集群状态
分布式消息传递
SpringCloud主要项目
Spring Cloud Config
Spring Cloud Netflix
Spring Cloud Bus
Spring Cloud Cloudfoundry
Spring Cloud Open Service Broker
Spring Cloud Cluster
Spring Cloud Consul
Spring Cloud Security
Spring Cloud Sleuth
Spring Cloud Data Flow
Spring Cloud Stream
Spring Cloud Stream App Starters
Spring Cloud Task
Spring Cloud Task App Starters
Spring Cloud Zookeeper
Spring Cloud AWS
Spring Cloud Connectors
Spring Cloud Starters
Spring Cloud CLI
Spring Cloud Contract
Spring Cloud Gateway
Spring Cloud OpenFeign
Spring Cloud Pipelines
Spring Cloud Function
Spring Cloud 是基于SpringBoot上开发的 分布式微服务架构的一站式解决方案，包括服务注册与发现，配置中心，服务网关，负载均衡，熔断器，全链路监控等
Spring Cloud 被称为构建分布式微服务系统的“全家桶”，它并不是某一门技术，而是一系列微服务解决方案或框架的有序集合。它将市面上成熟的、经过验证的微服务框架整合起来，并通过 Spring Boot 的思想进行再封装，屏蔽调其中复杂的配置和实现原理，最终为开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud发布的版本是一个按照字母顺序的伦敦地铁站的名字（“天使”是第一个版本，“布里克斯顿”是第二个），字母顺序是从A-Z，目前最新稳定版本 2021.0.x aka Jubilee，当Spring Cloud里面的某些子项目出现关键性bug或重大更新，则发布序列将推出名称以“.SRX”结尾的版本，其中“X”是一个数字，比如：Greenwich SR1、Greenwich SR2、Greenwich SR3
1、SpringCloud常用组件
Spring Cloud 本身并不是一个拿来即可用的框架，它是一套微服务规范，共有两代实现。
（1）Spring Cloud Netflix 是 Spring Cloud 的第一代实现，主要由 Eureka、Ribbon、Feign、Hystrix 等组件组成。
（2）Spring Cloud Alibaba 是 Spring Cloud 的第二代实现，主要由 Nacos、Sentinel、Seata 等组件组成。
Spring Cloud（特指 Spring Cloud Netflix） 中包含了 spring-cloud-config、spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。
Netflix 是美国的一个在线视频网站，它是公认的大规模生产级微服务的杰出实践者，微服务界的翘楚。Netflix 的开源组件已经在其大规模分布式微服务环境中经过了多年的生产实战验证，成熟且可靠。
Spring Cloud 将 Netflix 中的开源服务组件（如 Eureka 、Ribbon、Feign 以及 Hystrix 等）一起整合进 Spring Cloud Netflix 模块中，整合后的组件全称为 Spring Cloud Netflix XX，因此第一代 SpringCloud实现 也被称为 Spring Cloud Netflix
后续针对 Spring Cloud Netflix 和 Spring Cloud Alibaba都会进行区分
Spring Cloud （特指 Spring Cloud Netflix）常用组件如下表所示
| Spring Cloud 组件 | 描述 |
|---|---|
| Spring Cloud Netflix Eureka | Spring Cloud Netflix 中的服务治理组件，包含服务注册中心、服务注册与发现机制的实现。 |
| Spring Cloud Netflix Ribbon | Spring Cloud Netflix 中的服务调用和客户端负载均衡组件。 |
| Spring Cloud Netflix Hystrix | 人称“豪猪哥”，Spring Cloud Netflix 的容错管理组件，为服务中出现的延迟和故障提供强大的容错能力。 |
| Spring Cloud Netflix Feign | 基于 Ribbon 和 Hystrix 的声明式服务调用组件。 |
| Spring Cloud Netflix Zuul | Spring Cloud Netflix 中的网关组件，提供了智能路由、访问过滤等功能。 |
| Spring Cloud Gateway | 一个基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关框架，它使用 Filter 链的方式提供了网关的基本功能，例如安全、监控/指标和限流等。 |
| Spring Cloud Config | Spring Cloud 的配置管理工具，支持使用 Git 存储配置内容，实现应用配置的外部化存储，并支持在客户端对配置进行刷新、加密、解密等操作。 |
| Spring Cloud Bus | Spring Cloud 的事件和消息总线，主要用于在集群中传播事件或状态变化，以触发后续的处理，例如动态刷新配置。 |
| Spring Cloud Stream | Spring Cloud 的消息中间件组件，它集成了 Apache Kafka 和 RabbitMQ 等消息中间件，并通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件之间的隔离。通过向应用程序暴露统一的 Channel 通道，使得应用程序不需要再考虑各种不同的消息中间件实现，就能轻松地发送和接收消息。 |
| Spring Cloud Sleuth | Spring Cloud 分布式链路跟踪组件，能够完美的整合 Twitter 的 Zipkin。 |
2、SpringCloud和SpringBoot关联
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全 局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供:配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。
SpringBoot专注于快速、方便的开发单个个体微服务, SpringCloud关注全局的服务治理框架
Spring Boot 不需要 Spring Cloud，就能直接创建可独立运行的工程或模块
Spring Cloud 是基于 Spring Boot 实现的，它不能独立创建工程或模块，更不能脱离 Spring Boot 独立运行
Spring Cloud 与 Spring Boot的兼容版本对应关系如下（参考自Spring Cloud 官网）
3、Spring Cloud Netflix 架构图
Service Provider： 暴露服务的服务提供方
Service Consumer：调用远程服务的服务消费方。
EureKa Server： 服务注册中心和服务发现中心
参考文章
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
