中小企业对Spring Cloud微服务架构实践经验总结的少量思考!

作者 : 开心源码 本文共8531个字,预计阅读时间需要22分钟 发布时间: 2022-05-11 共75人阅读

Spring Cloud 在国内中小型公司可以使用起来吗?从 2016 年初一直到现在,我们在这条路上已经走了一年多。

在用 Spring Cloud 之前,我们对微服务实践是没有太多的体会和经验的。从最初的开源软件云收藏来熟习 Spring Boot,到项目中的慢慢用,再到最后全面拥抱 Spring Cloud。

这篇文章给大家详情我们用 Spring Boot / Cloud 一年多的经验总结。

在开始之前我们先详情几个概念,什么是微服务,它的特点是什么? Spring Boot / Cloud 都做了那些事情?他们三者之间又有什么关系?

什么是微服务

微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到:微服务架构是一种架构模式,它提倡将单一应使用程序划分成一组小的服务,服务之间互相协调、互相配合,为使用户提供最终价值。

每个服务运行在其独立的进程中,服务与服务间采使用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建,并且可以够被独立地部署到生产环境、类生产环境等。

另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

微服务是一种架构风格,一个大型复杂软件应使用由一个或者多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务可以力。

微服务架构优势

01

复杂度可控

在将应使用分解的同时,规避了本来复杂度无止境的积累。每一个微服务专注于单一功可以,并通过定义良好的接口清晰表述服务边界。

因为体积小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。

02

独立部署

因为微服务具有独立的运行进程,所以每个微服务也能独立部署。当某个微服务发生变更时无需编译、部署整个应使用。

由微服务组成的应使用相当于具有一系列可并行的发布流程,使得发布更加高效,同时降低对生产环境所造成的风险,最终缩短应使用交付周期。

03

技术选型灵活

微服务架构下,技术选型是去中心化的。每个团队能根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。

因为每个微服务相对简单,所以需要对技术栈进行更新时所面临的风险就较低,甚至完全重构一个微服务也是可行的。

04

容错

当某一组件发生故障时,在单一进程的传统架构下,故障很有可可以在进程内扩散,形成应使用全局性的不可使用。

在微服务架构下,故障会被隔离在单个服务中。若设计良好,其余服务可通过重试、平稳退化等机制实现应使用层面的容错。

05

扩展

单块架构应使用也能实现横向扩展,就是将整个应使用完整的复制到不同的节点。当应使用的不同组件在扩展需求上存在差异时,微服务架构便表现出其灵活性,由于每个服务能根据实际需求独立进行扩展。

什么是 Spring Boot

Spring Boot 是由 Pivotal 团队提供的全新框架,其设计目的是使用来简化新 Spring 应使用的初始搭建以及开发过程。该框架用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。

使用我的话来了解,就是 Spring Boot 不是什么新的框架,它默认配置了很多框架的用方式,就像 maven 整合了所有的 jar 包,Spring Boot 整合了所有的框架(不知道这样比喻能否合适)。

Spring Boot 简化了基于 Spring 的应使用开发,通过一些的代码就可以创立一个独立的、产品级别的 Spring 应使用。Spring Boot 为 Spring 平台及第三方库提供开箱即可使用的设置,这样你即可以有条不紊地开始。

Spring Boot 的核心思想就是商定大于配置,多数 Spring Boot 应使用只要要很少的 Spring 配置。采使用 Spring Boot 能大大的简化你的开发模式,所有你想集成的常使用框架,它都有对应的组件支持。

Spring Cloud 都做了哪些事

Spring Cloud 是一系列框架的有序集合,它利使用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设备的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都能使用 Spring Boot 的开发风格做到一键启动和部署。

Spring 并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过 Spring Boot 风格进行再封装、屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

以下为 Spring Cloud 的核心功可以:

分布式/版本化配置。

服务注册和发现。

路由。

服务和服务之间的调使用。

负载均衡。

断路器。

分布式消息传递。

我们再来看一张图:

解释一下这张图中各组件的运行流程:

所有请求都统一通过 API 网关(Zuul)来访问内部服务。

网关接收到请求后,从注册中心(Eureka)获取可使用服务。

由 Ribbon 进行均衡负载后,分发到后台的具体实例。

微服务之间通过 Feign 进行通信解决业务。

Hystrix 负责解决服务超时熔断。

Turbine 监控服务间的调使用和熔断相关指标。

当然上面只是 Spring Cloud 体系的一部分,Spring Cloud 共集成了 19 个子项目,里面都包含一个或者者多个第三方的组件或者者框架!

Spring Cloud 工具框架:

Spring Cloud Config,配置中心,利使用 git 集中管理程序的配置。?

Spring Cloud Netflix,集成众多 Netflix 的开源软件。

Spring Cloud Bus,消息总线,利使用分布式消息将服务和服务实例连接在一起,使用于在一个集群中传播状态的变化 。

Spring Cloud for Cloud Foundry,利使用 Pivotal Cloudfoundry 集成你的应使用程序。

Spring Cloud Foundry Service Broker,为建立管理云托管服务的服务代理商提供了一个起点。

Spring Cloud Cluster,基于 Zookeeper、Redis、Hazelcast、Consul 实现的领导选举和平民状态模式的笼统和实现。

Spring Cloud Consul,基于 Hashicorp Consul 实现的服务发现和配置管理。

Spring Cloud Security,在 Zuul 代理商中为 OAuth2 rest 用户端和认证头转发提供负载均衡。

Spring Cloud Sleuth Spring Cloud,应使用的分布式追踪系统和 Zipkin、HTrace、ELK 兼容。

Spring Cloud Data Flow,一个云本地程序和操作模型,组成数据微服务在一个结构化的平台上。

Spring Cloud Stream,基于 Redis、Rabbit、Kafka 实现的消息微服务,简单公告模型使用以在 Spring Cloud 应使用中收发消息。

Spring Cloud Stream App Starters,基于 Spring Boot 为外部系统提供 Spring 的集成。

Spring Cloud Task,短生命周期的微服务,为 Spring Boot 应使用简单公告增加功可以和非功可以特性。

Spring Cloud Task App Starters。

Spring Cloud Zookeeper,服务发现和配置管理基于 Apache Zookeeper。

Spring Cloud for Amazon Web Services,快速和亚马逊网络服务集成。

Spring Cloud Connectors,便于 PaaS 应使用在各种平台上连接到后台像数据库和消息经纪服务。

Spring Cloud Starters,项目已经终止并且在 Angel.SR2 后的版本和其余项目合并。

Spring Cloud CLI,插件使用 Groovy 快速的创立 Spring Cloud 组件应使用。

这个数量还在一直添加…

三者之间的关系

微服务是一种架构的理念,提出了微服务的设计准则,从理论为具体的技术落地提供了指导思想。

Spring Boot 是一套快速配置脚手架,能基于 Spring Boot 快速开发单个微服务。

Spring Cloud 是一个基于 Spring Boot 实现的服务治理工具包;Spring Boot 专注于快速、方便集成的单个微服务个体;Spring Cloud 关注全局的服务治理框架。

Spring Boot / Cloud 是微服务实践的最佳落地方案。

Spring Boot / Cloud 微服务实践背景

2015 年初的时候,由于公司业务的大量发展,我们开始对原有的业务进行拆分,新上的业务线也一律用独立的项目来开发,项目和项目之间通过 http 接口进行访问。

2015 年的业务发展非常迅速,项目数量也就相应急剧扩大,到了年底的时候项目达 60 多个,当项目数达到 30 几个的时候,我们就遇到了问题,经常某个项目由于扩展添加了新的 IP 地址,就需要被动的升级好几个相关的项目。

服务越来越多,服务之间的调使用关系也越来越复杂,有时候想画一张图来表示项目和项目之间的依赖关系,线条密密麻麻无法看清。下面有一张图能表达我们的心情:

这个时候我们就想找一种方案,能将我们这么多分布式的服务给管理起来,到网上进行了技术调研我们发现有两款开源软件比较适合我们,一个是 Dubbo,另一个是 Spring Cloud。

刚开始我们是走了少量弯路的,这两款框架我们都不熟习,当时国内用 Spring Cloud 进行开发的企业非常的少,我在网上也几乎没找到太多应使用的案例。但是 Dubbo 在国内的用还是挺普遍的,相关的资料各方面都比较完善。

因而在公司扩展新业务线众筹平台的时候,技术选型就先定了 Dubbo,由于也是全新的业务没有什么负担,这个项目我们大概开发了 6 个月投产,上线之初也遇到了少量问题,但最终还比较顺利。

在新业务线选型用 Dubbo 的同时,我们也没有完全放弃 Spring Cloud,我们抽出了一两名开发人员学习 Spring Boot,我也参加其中。

为了验证 Spring Boot 能否能到达实战的标准,我们在业余的时间用 Spring Boot 开发了一款开源软件云收藏,经过这个项目的实战验证我们对 Spring Boot 就有了信心。

最重要的是大家体会到用 Spring Boot 的各种便利之后,就再也不想用传统的方式来进行开发了。

但是还有一个问题,在选择了 Spring Boot 进行新业务开发的同时,并没有处理我们上面的那个问题,服务与服务直接调使用依然比较复杂和传统,这时候我们就开始研究 Spring Cloud。

由于大家在前期对 Spring Boot 有了足够的理解,因而学习 Spring Cloud 就显得顺风顺水了。所以在用 Dubbo 半年之后,我们又全面开始拥抱 Spring Cloud。

为什么选择用 Spring Cloud 而放弃了 Dubbo

可可以大家会问,为什么选择了用 Dubbo 之后,又选择全面用 Spring Cloud 呢?其中有如下四个起因:

01

从两个公司的背景来谈

Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应使用于中国各互联网公司;Spring Cloud 是大名鼎鼎的 Spring 家族的产品。

阿里巴巴是一个商业公司,尽管也开源了很多的顶级的项目,但从整体战略上来讲,依然是服务于自身的业务为主。

Spring 专注于企业级开源框架的研发,不管是在中国还是在世界上用都非常广泛,开发出通使用、开源、稳健的开源框架是他们的主业。

02

从社区活跃度这个角度来比照

Dubbo 尽管也是一个非常优秀的服务治理框架,并且在服务治理、灰度发布、流量分发这方面做的比 Spring Cloud 还好,除过当当网在此基础上添加了 rest 支持外,已有两年多的时间几乎没有任何升级了。

在用过程中出现问题,开发者提交到 GitHub 的 Issue 也少有回复。相反 Spring Cloud 自从发展到现在,依然在不断的高速发展。

从 GitHub 上提交代码的频度和发布版本的时间间隔即可以看出,现在 Spring Cloud 即将发布 2.0 版本,到了后期会更加完善和稳固。

03

从整个大的平台架构来讲

Dubbo 框架只是专注于服务之间的治理,假如我们需要用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中添加了用 Dubbo 的难度。

Spring Cloud 几乎考虑了服务治理的方方面面,更有 Spring Boot 这个大将的支持,开发起来非常的便利和简单。

04

从技术发展的角度来讲

Dubbo 刚出来的那会技术理念还是非常先进,处理了各大互联网公司服务治理的问题,中国的各中小公司也从中受益不少。

经过了这么多年的发展,互联网行业也是涌现了更多先进的技术和理念,Dubbo 一直停滞不前,自然有些掉队,有时候我个人也会感到有点可惜,假如 Dubbo 一直沿着当初的那个路线发展,并且延伸到周边,今天可可以又是另一番景象了。

Spring 推出Spring Boot / Cloud 也是由于自身的很多起因。Spring 最初推崇的轻量级框架,随着不断的发展也越来越庞大,随着集成项目越来越多,配置文件也越来越混乱,慢慢的背离最初的理念。

随着这么多年的发展,微服务、分布式链路跟踪等更多新的技术理念的出现,Spring 急需一款框架来改善以前的开发模式,因而才会出现 Spring Boot / Cloud 项目。

我们现在访问 Spring 官网,会发现 Spring Boot 和 Spring Cloud 已经放到首页最重点突出的三个项目中的前两个,可见 Spring 对这两个框架的重视程度。

因而 Dubbo 曾经的确很牛逼,但是 Spring Cloud 是站在近些年技术发展之上进行的开发,因而更具技术代表性。

如何进行微服务架构演进

当我们将所有的新业务都用 Spring Cloud 这套架构之后,就会出现这样一个现象:公司的系统被分成了两部分,一部分是传统架构的项目;另一部分是微服务架构的项目,如何让这两套配合起来用就成为了关键。

这时候 Spring Cloud 里面的一个关键组件处理了我们的问题,就是 Zuul。在 Spring Cloud 架构体系内的所有微服务都通过 Zuul 来对外提供统一的访问入口,所有需要和微服务架构内部服务进行通讯的请求都走统一网关。如下图:

从上图能看出我们对服务进行了四种分类,不同服务迁移的优先级不同:

基础服务,是少量基础组件,与具体的业务无关。比方:短信服务、邮件服务。这里的服务最容易摘出来做微服务,也是我们第一优先级分离出来的服务。

业务服务,是少量垂直的业务系统,只解决单一的业务类型,比方:风控系统、积分系统、合同系统。

这类服务职责比较单一,根据业务情况来选择能否迁移,比方:假如忽然有需求对积分系统进行大优化,我们就趁机将积分系统进行改造,是我们的第二优先级分离出来的服务。

前置服务,前置服务一般为服务的接入或者者输出服务,比方网站的前台服务、app 的服务接口这类,这是我们第三优先级分离出来的服务。

组合服务,组合服务就是涉及到了具体的业务,比方买标过程,需要调使用很多垂直的业务服务,这类的服务我们一般放到最后再进行微服务化架构来改造,由于这类服务最为复杂,除非涉及到大的业务逻辑变更,我们是不会轻易进行迁移。

在这四类服务之外,新上线的业务一律用 Sprng Boot / Cloud 这套技术栈。

架构演化的步骤

架构演化的步骤如下:

在确定用Spring Boot / Cloud 这套技术栈进行微服务改造之前,请先梳理平台的服务,对不同的服务进行分类,以确认演化的节奏。

先让团队熟习 Spring Boot 技术,并且优先在基础服务上进行技术改造,推动改动后的项目投产上线。

当团队熟习 Spring Boot 之后,再推进用 Spring Cloud 对原有的项目进行改造。

在进行微服务改造过程中,优先应使用于新业务系统,前期能只是一些的项目进行了微服务化改造,随着大家对技术的熟习度添加,能加快加大微服务改造的范围。

传统项目和微服务项目共存是一个很常见的情况,除非公司业务有大的变化,不建议直接迁移核心项目。

服务拆分

服务拆分的两个准则:

横向拆分。按照不同的业务域进行拆分,例如订单、营销、风控、积分资源等,形成独立的业务领域微服务集群。

纵向拆分。把一个业务功可以里的不同板块或者者组件进行拆分。例如把公共组件拆分成独立的原子服务,下沉究竟层,形成相对独立的原子服务层。这样一纵一横,即可以实现业务的服务化拆分。

要做好微服务的分层:梳理和抽取核心应使用、公共应使用,作为独立的服务下沉到核心和公共可以力层,逐步形成稳固的服务中心,使前台应使用可以更快速的响应多变的市场需求。

服务拆分是越小越好吗?微服务的大与小是相对的。比方在初期,我们把交易拆分为一个微服务,但是随着业务量的增大,可可以一个交易系统已经慢慢变得很大,并且并发流量也不小。

为了支撑更多的交易量,我会把交易系统,拆分为订单服务、招标服务、转让服务等。因而微服务的拆分力度需与具体业务相结合,总的准则是服务内部高内聚,服务之间低耦合。

微服务 vs 传统开发

用微服务有一段时间了,这种开发模式和传统的开发模式比照,有很大的不同,如下面几点:

分工不同,以前我们可可以是一个一个板块,现在可可以是一人一个系统。

架构不同,服务的拆分是一个技术含量很高的问题,拆分能否正当对以后发展影响巨大。

部署方式不同,假如还像以前一样部署预计累死了,自动化运维不可不上。

容灾不同,好的微服务能隔离故障避免服务整体 down 掉,坏的微服务设计依然能由于一个子服务出现问题导致连锁反应。

给数据库带来的挑战

每个微服务都有自己独立的数据库,那么后端管理的联合查询怎样解决?这是大家普遍遇到的一个问题。

有如下三种解决方案:

严格按照微服务的划分来做,微服务相互独立,各微服务数据库也独立,后端需要展现数据时,调使用各微服务的接口来获取对应的数据,再进行数据解决后展现出来,这是标准的使用法,也是最麻烦的使用法。

将业务相关的表放到一个库中,将业务无关的表严格按照微服务模式来拆分,这样既能用微服务,也避免了数据库各种切换导致后端统计难以实现,是一个折中的方案。

数据库严格按照微服务的要求来切分,以满足业务高并发,实时或者者准实时将各微服务数据库数据同步到 NoSQL 数据库中,在同步的过程中进行数据清洗,使用来满足后端业务系统的用,推荐用 Mongodb、Hbase 等。

三种方案在不同的公司我都用过,第一种方案适合业务较为简单的小公司;第二种方案,适合想在原有系统之上,慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。

微服务的经验和建议

01

建议尽量不要用 Jsp,页面开发推荐用 Thymeleaf

Web 项目建议独立部署 Tomcat,不要用内嵌的 Tomcat,内嵌 Tomcat 部署 Jsp 项目会偶现龟速访问的情况。

02

服务编排是个好东西,主要的作使用是减少项目中的相互依赖

比方现在有项目 a 调使用项目 b,项目 b 调使用项目 c…一直到 h,是一个调使用链,那么项目上线的时候需要先升级最底层的 h 再升级 g…升级 c 升级 b 最后是升级项目 a。

这只是一个调使用链,在复杂的业务中有非常多的调使用,假如要记住每一个调使用链对开发运维人员来说就是灾难。

有一个好办法能尽量的减少项目间的相互依赖,就是服务编排,一个核心的业务解决项目,负责和各个微服务打交道。

比方之前是 a 调使用 b,b 掉使用 c,c 调使用 d,现在统一在一个核心项目 W 中来解决,W 服务用 a 的时候去调使用 b,用 b 的时候W去调使用 c。

举个例子:在第三方支付业务中,有一个核心支付项目是服务编排,负责解决支付的业务逻辑,W 项目用商户信息的时候就去调使用“商户系统”,需要校验设施的时候就去调使用“终端系统”,需要风控的时候就调使用“风控系统”,各个项目需要的依赖参数都由W来做主控。以后项目部署的时候,只要要最后启动服务编排项目就可。

03

不要为了追求技术而追求技术

需要考虑以下几方面的因素:

团队的技术人员能否已经具有相关技术基础。

公司业务能否适合进行微服务化改造,并不是所有的平台都适合进行微服务化改造,比方:传统行业有很多复杂垂直的业务系统。

Spring Cloud 生态的技术有很多,并不是每一种技术方案都需要使用上,适合自己的才是最好的。

总结

Spring Cloud 对于中小型互联网公司来说是一种福音,由于这类公司往往没有实力或者者没有足够的资金投入去开发自己的分布式系统基础设备,用 Spring Cloud 一站式处理方案可以在从容应对业务发展的同时大大减少开发成本。

同时,随着近几年微服务架构和 Docker 容器概念的火爆,也会让 Spring Cloud 在未来越来越“云”化的软件开发风格中立有一席之地。

尤其是在目前五花八门的分布式处理方案中提供了标准化的、全站式的技术方案,意义可可以堪比当前 Servlet 规范的诞生,有效推进服务端软件系统技术水平的进步。

迎工作一到五年的Java程序员朋友们加入Java架构开发:744677563

本群提供免费的学习指导 架构资料 以及免费的解答

不懂得问题都能在本群提出来 之后还会有职业生涯规划以及面试指导

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 中小企业对Spring Cloud微服务架构实践经验总结的少量思考!

发表回复