大家好，给大家先做个自我介绍
我是码上代码，大家可以叫我码哥
我也是一个普通本科毕业的最普通学生，我相信大部分程序员或者想从事程序员行业的都是普通家庭的孩子，所以我也是靠自己的努力，从毕业入职到一家传统企业，到跳槽未尝败绩，现在在一家某互联网行业巨头公司工作，希望可以通过自己的分享对大家有一些帮助
跟随我的专栏学习，可以省去你很多去培训的费用或者网上找资料的时间，节省你的大部分时间成本，让你更加快速成为面试收割机，年度最佳员工我为大家准备了16个技术专栏带领大家一起学习
有什么想学习的技术可以评论区留言，一起进步
微服务架构介绍
- 微服务架构出现
- 微服务架构流派
- 云原生与微服务
- 总结
- 福利
近年来，微服务架构一直是互联网技术圈的热点之一，越来越多的互联网应用都采用了微服务架构作为系统构建的基础，很多新技术和理念如 Docker
、Kubernetes 、DevOps 、持续交付、Service Mesh 等也都在关注、支持和跟随微服务架构的发展 。
本章将会概要性地介绍微服务架构：包括微服务架构是如何演进的，微服务架构的主要流派，当前主流的云原生应用与微服务之间的关系等 。
微服务架构的出现
从单体应用架构发展到 SOA 架构，再到微服务架构，应用架构经历了多年的不断演进 。 微服务架构不是凭空产生的，而是技术发展的必然结果，分布式云平台的应用环境使得微服务代替单体应用成为互联网大型系统的架构选择 。目前，虽然微服务架构还没有公认的技术标准和规范草案，但业界已经有了一些很有影响力的开源微服务架构解决方案，在进行微服务化开发或改造时可以进行相应的参考 。
单体应用架构
与微服务架构对比的是传统的单体应用 。Web 应用程序发展的早期，大部分 Web 工程是将所有的功能模块打包到一起部署和运行，例如 Java 应用程序打包为一个 war 包，其他语言（ Ruby 、Python 或者 C＋＋）编写的应用程序也有类似的做法 。 单体应用的实现架构类似于图1-1 中的电影售票系统 。
这个电影售票系统采用分层架构，按照调用顺序，从上到下为表示层、业务层、数据访问（ DAO ）层、 DB 层 。 表示层负责用户体验；业务层负责业务逻辑，包括电影、订单和用户 三个模块；数据访问层负责 DB 层的数据存取， 实现增删改查的功能 。 业务层定义了应用的业务逻辑，是整个应用的核心 。
但是，随着应用项目变得复杂 、开发团 队不断扩张之后，单体应用的不足和弊端将会变得很明显，主要有如下不足：
- 可靠性：每个 bug 都可能会影响到整个应用的可靠性 。 因为所有模块都运行在一个进程中，任何一个模块中 的一个 bug ，比如内存泄露，都可能拖垮整个进程 。
- 复杂性高：单体应用巨大的代码库可能会令人望而生畏，特别是对团队新成员来说 。 应用难以理解和迭代，进而导致开发速度减慢 。 由于没有清晰的模块边界，模块化会逐渐消失 。
- 持续部署困难： 巨大的单体应用本身就是频繁部署 的一大障碍。为了更新一个组件，必须重新部署整个应用 。 这会中断那些可能与更改无关的后台任务（例如 Java 应用中的 Quartz 任务），同时可能引发其他问题 。 另外，未被更新的组件有可能无法正常启动 。 重新部署会增加风险，进而阻碍频繁更新 。
- 扩展能力受限：单体架构只能进行一维扩展 。 一方面，它可以通过运行多个应用服 务实例来增加业务容量，实现扩展 。但另一方面，不同的应用组件有不同的资源需 求 ： 有的是 CPU 密集型的，有的是内存密集型的 。 单体架构无法单独扩展每个组件 。
- 阻碍技术创新：
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引人新的框架或技术平台非常困难 。单体架构迫使团队长期使用在开发初期选定的技术枝，比如选择了 JVM 的语言， 此时以非 JVM 语言编写的组件就无法在该单体架构的应用中使用 。
SOA 架构
面向服务的架构（ SOA ）是 Gartner 于 20 世纪 90 年代中期提出的 。
2002 年 12 月，Gartner提出“面向服务的架构”是现代应用开发领域最重要的课题之一 。
SOA 的核心主体是服务，其目标是通过服务的流程化来实现业务的灵活性 。服务就像一堆“元器件”，这些元器件通过封装形成标准服务，它们有相同的接口和语义表达规则 。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务 、 如何发现服务、如何包装服务的安全性和可靠性，这些就是 SOA 治理 。SOA 治理是将 SOA 的一堆元器件进行有效组装 。 这是形成一个“产品”的关键，否则那些永远是一堆元器件，而无法形成一个有机整体 。
完整的 SOA 架构由五大部分组成：基础设施服务 、 企业服务总线 、 关键服务组件、开发工具、管理工具等 。
- 基础设施： 为整个 SOA 组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑 。
- 企业服务总线： 提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式 。
- 关键服务组件：SOA 在各种业务服务组件的分类 。
- 开发工具和管理工具： 提供完善的、可视化的服务开发和流程编排工具，包括服务的设计、开发 、 配置、部署、监控、重构等完整的 SOA项目开发生命周期 。
微服务架构
微服务最早是由 Martin Fowler 与 Jam es Lewis 于 2014 年共同提出，需要了解细节的读者可以阅览 http s 😕/martinfow !er. com/arti cles/rn icroservices.h trn l 。 其实 Martin 先生并没有给出明确的微服务定义，根据其描述，微服务的定义可以概括如下：微服务架构是一种使用一系列粒度较小 的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采
用轻量级的方式进行通信（通常是 HTTPAPI) ；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术 。
如今，微服务架构已经不是一个新概念了，很多业界前沿互联网公司的实践表明，微服务是一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段 。
组成
微服务架构是一种比较复杂、内涵丰富的架构模式，它包含很多支撑“微”服务的具体组件和概念，其中一些常用的组件及其概念如下：
- 服务注册与发现：
服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址 。 - 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点 。并且，服务节点选择的过程对服务调用方来说是透明的 。
- 服务网关：服务网关是服务调用的唯一人口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能 。口配置中心：将本地化的配置信息（ Properties 、 XML 、YAML等形式）注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移 。
- 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统 。
- 调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来 。 在系统出错时，可以方便地找到出错点 。
- 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化 。 现在，Docker 等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能健康等等 。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效 。
优点
微服务架构模式有很多优势可以有效解决单体应用扩大之后出现的大部分问题 。 首先，通过将巨大单体式应用分解为多个服务的方法解决了复杂性 问题 。 在功能不变的情况下，应用分解为多个可管理的模块或服务 。 每个服务都有一个用 RPC 或者消息驱动 API 定义清楚的边界 。 微服务架构模式为采用单体式编码方式很难实现的功能提供了模块化的解决方案 。 由此，单个服务变得很容易开发、理解和维护 。
其次，微服务架构模式使得团队并行开发得以推进，每个服务都可以由专门开发团队来开发 。 不同团队的开发者可以自由选择开发技术，提供 API 服务 。 这种自由意味着开发者不需要被迫使用之前采用的过 时技术，他们可以选择最新 的技术 。 甚至于，因为服务都是相对简单的，即使用新技术重写以前的代码也不是很困难的事情 。
再次，微服务架构模式中每个微服务独立都是部署的 。 理想情况下，开发不需要协调其他服务部署对本服务的影响 。 这种改变可以加快部署速度 。ur 团队可以采用 AB 测试，快速地部署变化 。 微服务架构模式使得持续化部署成为可能 。最后 ， 微服务架构模式使得每个服务易于独立扩展 。
挑战
微服务的一些想法是好的，但在实践中也会呈现出其复杂性，具体如下 ：
- 运维要求较高 。 更多的服务意味着需要更多的运维投入 。 在单体架构中只需要保证一个应用的正常运行即可·而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，这带来了巨大的挑战 。
- 复杂性 。 使用微服务构建的是分布式系统 。 对于一个分布式系统来说，系统容错 、网络延迟 、 分布式事务等都会带来巨大的挑战
- 接口调整成本高 。 微服务之间通过接口进行通信 。 如果修改某个微服务的 API ，可能所有使用了该接口 的微服务都需要做调整 。
- 重复劳动
很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这－功能，导致代码重复 。 - 可测试性的挑战 。 在动态环境下，服务间的交互会产生非常微妙的行为，难以进行可视化及全面测试 。
微服务架构的流派
常见的微服务架构方案有四种，分别是 ZeroC IceGrid 、 基于消息 队列 、Docker Swarm和 Spring Cloud 。 下面分别介绍这四种方案 。
ZeroC IceGrid
ZeroC IceGrid 是基于 RPC 框架 Ice 发展而来的一种微服务架构，
Ice 不仅仅是一个 RPC框架，它还为网络应用程序提供了 一些补充服务 。
Ice 是一个全面的 RPC 框架， 支持 C＋＋、C＃、Java 、JavaScript 、Python 等语言 。IceGrid 具有定位、部署和管理 Ice 服务器的功能，具有良好的性能与分布式能力.
基于消息队列
在微服务架构的定义中讲到，各个微服务之间使用“轻量级”的通信机制 。 所谓轻量级，是指通信协议与语言无关 、 与平台无关 。 微服务之间的通信方式有两种：同步和异步 。同步方式有 RPC ,REST 等；除了标准的基于 同步通信方式的微服务架构外 ，还有基于消息队列异步方式通信的微服务架构 。
Docker Swarm
Swarm 项目是 Docker 公司发布的三剑客中的一员，用来提供容器集群服务 ，目的 是更好地帮助用户管理多个 Docker Eng ine ，方便用户使用 。 通过把多个 Docker Engine 聚集在一起，形成一个大的 Docker Engine ，对外提供容器的集群服务 。 同时这个集群对外提供Swarm API ，用户可以像使用 Docker Eng in e 一样使用 Docker 集群 。
Spring Cloud
Spring Cloud 是一个基于 Spring Boot 实现的 云应用开发工具，是一系 列框架的集合，当添加这些工具库到应用后会增强应用的行为 。Spring Boot 秉持约定优于配置的思想，因此可以利用这些组件基本的默认行为来快速入 门 ，并在需要的时候可以配置或扩展，以创建自定义解决方案 。
Spring C l oud 利用 Spring Boot 的开发便利性，巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以基于 Spring Boot 组件进行开发，做到 一键启动和部署 。Spring Cloud 并没有重复制造轮子，它只是将目前比较成熟、经得起实际考验、优秀的开源服务框架组合起来，通 过 SpringBoot 进行封装 ， 屏蔽掉复杂的配置和实现原理 ， 最终给开发者留了 一套简单易懂、易部署和易维护的分布式系统开发工具包 。
以下为 Spring C loud 的核心功能 ：
- 分布式／版本化配置
- 服务注册和发现
- 服务路由
- 服务和服务之间的调用
- 负载均衡
- 断路器
- 分布式消息传递
还有很多基础的功能没有列出，每个功能对应 S pring C loud 中的 一 个组件，包括Spring Cloud Confi g 、S p ri ng Cloud Netflix (Eureka 、Hys tri x 、Zuul 、Archaius …）、SpringCloud Bus 等组件 。
云原生与微服务
提及云原生，首先需要了解一下 CNCF ，即云原生计算基金会，
2 015 年由谷歌牵头成立，基金会成员目前已有一百多个企业与机构，包括亚马逊、微软、思科等巨头 。目 前CNCF 所托管的应用已达 14 个，知名的项目有 Kubernetes 、Prometheus 、Envoy 等 。
云原生
CNCF 宪章中给出了云原生应用的三大特征，概括如下 ：
- 窑器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护 。 在容器中运行应用程序和进程，并作为应用程序部署 的独立单元，实现高水平资源隔离 。
- 动态管理：通过集中式的编排调度系统来动态管理和调度 。
- 面向微服务 ：明确服务间的依赖，互相解耦。
云原生包含了 一组应用的模式，用于帮助企业快速、持续、可靠、规模化地交忖业务软件 。 如图1-7 所示， 云原生 由微服务架构、DevOps 和以容器为代表的敏捷基础架构组成 。
总结
单体模式开发速度很快，但是随着五联网用户的高速增长，已经变得不适应如此大用户量的应用 。 架构的演进从单体到 SOA ，再到微服务架构，技术的发展遵循一定的规律，使得移动互联网的发展在技术上得到了支持 。 微服务架构是 SOA 思想的一种具体实践 。 微服务架构将早期的单体应用从数据存储开始垂直拆分成多个不同的服务，每个服务都能独立部署，独立维护，独立扩展，服务与服务间通过诸如 RESTful的方式互相调用 。
微服务架构并不能解决所有问题，所以一定要慎重考虑何时采用微服务，只有业务复杂到一定程度的时候才适合采用微服务架构 。 微服务的理念和框架，使得它对团队的要求比较高，需要团队所有成员都要认可微服务的理念和治理框架，否则执行过程中会有很多问题 。
后续
后续将为大家详细讲解springcloud每个技术组件的使用及原理，请大家保持关注
五分钟学会 Spring Cloud Eureka：服务注册与发现（小白必看，一看就会教程）
五分钟学会 Spring Cloud Ribbon：负载均衡的服务调用（小白必看，一看就会教程）
五分钟学会 Spring Cloud Hystrix：服务容错保护（小白必看，一看就会系列教程）
五分钟学会 Spring Cloud Zuul：API网关服务（小白必看，一看就会教程）
五分钟学会 Spring Cloud Config：外部集中化配置管理（小白必看，一看就会教程）
五分钟学会 Spring Cloud Sleuth：分布式请求链路跟踪（小白必看，一看就会教程）
五分钟学会 Spring Cloud Consul：服务治理与配置中心（小白必看，你看就会教程）
五分钟学会 Spring Boot Admin：微服务应用监控（小白必看，一看就会教程）
五分钟学会 Spring Cloud Alibaba：Nacos 作为注册中心和配置中心使用（小白必看，一看就会教程）
扫一扫
89
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
