Browsed by
标签:Spring Cloud

云原生:「落地」最重要

云原生:「落地」最重要

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了,但到底怎么去理解它,还是需要一段过程。提到云原生,很多人会联想到另一个词:「互联网原住民」,这个词代表了一群出生在互联网时代的人,他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统,不再是原来的那套思考方式,不是把云当成一个工具来使用,而是系统本身就生长于云,并在云上爆发,因此需要我们从根本上转换思考方式,重新定义业务系统。云原生和云计算也不一样,云计算的主角是计算、机器、资源,而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事: 在 2004 年那个缺电的夏天,淘宝网全都挤在华星二楼:正是在那里,开始了我的淘宝生涯。我的位置在一个角落里,边上是一堆开着的服务器,吹出的风比七月烈阳下的风更热:因为限电,空调基本上只能看。刚到一个新环境,不知道该做什么,眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的,我记得小宝有一次说,当时网站如果要改点什么,只要跑到多隆那儿说一下,等他接杯水回到座位打开页面时,需求就已经上线了。 那是 2004 年,基于当时的技术架构,任何需求只要改一下代码,就能够立刻交付。而在现在这样复杂的技术架构下,很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来,我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

当我们谈注册中心时谈什么?

当我们谈注册中心时谈什么?

閱讀本文約花費: 11 (分鐘)最近工作重心转向了注册中心,于是想来写一篇关于注册中心的文章 概念 什么是注册中心,以大多数人熟悉的RPC框架来说,通常RPC中有三种角色: provider 服务提供者 consumer 服务消费者,即调用方 registry 注册中心,让consumer能发现provider的关键 注册中心对于服务提供者需要具备服务注册、注销的能力,对于服务消费者需要提供查询服务、感知服务变化的功能。当然还需要解决一些其他问题才能成为一个优秀的注册中心,如高可用、高性能、水平扩展能力、服务探活能力、路由功能、多机房(多活)能力等。 特性详解 存储 可以将注册中心理解为一个存储系统,存储着服务名与服务提供方的映射表。由此可见DNS是目前使用最广泛的注册中心。一般注册中心对存储没有什么要求,甚至你可以基于数据库来实现一个注册中心。 高可用 在聊高可用前,假定你了解分布式CAP理论,如果不知道可以稍微网上查一下,这里就不赘述。 其中对注册中心的高可用要求尤其高,它有如下几层含义,首先肯定是集群部署,无单点问题,其次就算整个集群挂掉了,也不能影响现有服务的调用,只不过现有的调用关系无法及时改变而已。 在分布式理论CAP中,注册中心更理想的应该是AP模式。(此结论更多讨论参考文末的《阿里巴巴为什么不用ZooKeeper做服务发现》),可以简单的从以下两个场景来理解:​ 注…

Read More Read More

Nacos 企业级落地实践

Nacos 企业级落地实践

閱讀本文約花費: 16 (分鐘)前言 在高速发展的时候,公司规模越来越大,老师人数越来越多,这时候公司不能铺太多人去做运营与服务,必须提高每个人效,这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司,如果被迫成为一家靠资金驱动的公司就活不下去了。 ——张翼(掌门教育创始人兼 CEO) 掌门教育自 2014 年正式转型在线教育以来,秉承“让教育共享智能,让学习高效快乐”的宗旨和愿景,经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ,一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展,特别是今年的疫情,使在线教育成为了新的风口,也给掌门教育新的机遇。 随着业务规模进一步扩大,流量进一步暴增,微服务数目进一步增长,使老的微服务体系所采用的注册中心 Eureka 不堪重负,同时 Spring Cloud 体系已经演进到第二代,第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模,同时它目前被 Spring Cloud 官方置于维护模式,将不再向前发展。如何选择一个更为优秀和适用的注册中心,这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、HashiCorp Consul 等开源注册中心做了深入的调研和比较,最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 掌门教育微服务面临…

Read More Read More

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

微服务写的最全的一篇文章

微服务写的最全的一篇文章

閱讀本文約花費: 14 (分鐘) 本文来自于网络,本文主要讲解的是微服务,详细阐述了微服务的利弊、服务分层、微服务的服务发现的三种方式微服务的路由发现体系等相关知识。 今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可) 2)独立的进程(java的tomcat,nodejs等) 3)轻量级的通信(不是soap,是http协议) 4)基于业务能力(类似用户服务,商品服务等等) 5)独立部署(迭代速度快) 6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择) ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。 2. 怎么权衡微服务的利于弊 利: 强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活) 可独立部署。 技术多样性。 弊: 分布式复杂性。 最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题) 运维复杂性。 测试复杂性。 3. 企业在什么时候考虑引入微服务 从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的…

Read More Read More

SpringCloud Alibaba——服务注册与发现(Nacos)

SpringCloud Alibaba——服务注册与发现(Nacos)

閱讀本文約花費: 5 (分鐘)一、Nacos简介 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 安装Nacos 下载地址(版本:0.7.0) Linux:sh startup.sh? Windows:startup.cmd? 访问:http://127.0.0.1:8848/nacos,可以进入Nacos的服务管理页面: 二、SpringCloud整合Nacos 完成了Nacos服务的安装和启动之后,下面就可以编写两个应用(服务提供者与服务消费者)来验证服务的注册与发现了。 spring cloud的版本以及spring cloud alibaba的版本,由于spring cloud alibaba还未纳入spring cloud的主版本管理中,所以需要自己加入,添加依赖文件(父工程): <properties><java.version>1.8</java.version><spring-cloud.version>Finchley.RELEASE</spring-cloud….

Read More Read More

第九章 Nacos Config–服务配置

第九章 Nacos Config–服务配置

閱讀本文約花費: 8 (分鐘) 本文介绍微服务架构下关于配置文件的一些问题,Nacos Config入门及深入,nacos的几个概念等,更多请看下文。 9.1 服务配置中心介绍 首先我们来看一下,微服务架构下关于配置文件的一些问题: 配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统一配置和管理。 配置文件无法区分环境。微服务项目可能会有多个环境,例如:测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的,一旦需要修改,就需要我们去各个微服务下手动 维护,这比较困难。 配置文件无法实时更新。我们修改了配置文件之后,必须重新启动微服务才能使配置生效,这对一 个正在运行的项目来说是非常不友好的。 基于上面这些问题,我们就需要配置中心的加入来解决这些问题。 配置中心的思路是: 首先把项目中各种配置全部都放到一个集中的地方进行统一管理,并提供一套标准的接口。 当各个服务需要获取配置的时候,就来配置中心的接口拉取自己的配置。 当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来同步最新的信息,使之动态更新。 当加入了服务配置中心之后,我们的系统架构图会变成下面这样: 在业界常见的服务配置中心,有下面这些: Apollo Apollo是由携程开源的分布式配置中心。特点有很多,比如:配置更新之后可以实时生效,…

Read More Read More

第五章 Gateway–服务网关

第五章 Gateway–服务网关

閱讀本文約花費: 15 (分鐘) 接上一篇文章开始网关之旅,首先告诉大家网关是什么,Gateway简介,怎么配置,怎么入门,执行流程等等相关介绍。 大家都都知道在微服务架构中,一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢?如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去 用。 这样的架构,会存在着诸多的问题: 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证复杂,每个服务都需要独立认证。 存在跨域请求,在一定场景下处理相对复杂。 上面的这些问题可以借助API网关来解决。 所谓的API网关,就是指系统的统一入口,它封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、路由转发等等。 添加上API网关之后,系统的架构图变成了如下所示: 我们也可以观察下,我们现在的整体架构图: 在业界比较流行的网关,有下面这些: Ngnix+lua 使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用 lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本 Kong 基于Nginx+Lua开发,性能高,稳定,有多个可用的插件(限流、鉴权等等)可以开箱即用。问题: 只支持Http协议;二次开发,自由扩展困难;提供管理API,缺乏更易用…

Read More Read More

第四章 Sentinel–服务容错

第四章 Sentinel–服务容错

閱讀本文約花費: 30 (分鐘) 从高并发带来的问题的问题说起 ,讲解服务雪崩效应,常见容错方案,Sentinel基础,相关的应用规则等。 4.1 高并发带来的问题 在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。 接下来,我们来模拟一个高并发的场景 @[email protected] class OrderController2 {@Autowiredprivate OrderService orderService;@Autowiredprivate ProductService productService;@RequestMapping(“/order/prod/{pid}”)public Order order(@PathVariable(“pid”) Integer pid) {log.info(“接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息”, pid); //调用商品微服务,查询商品信息Product product = productService.find…

Read More Read More

第三章 Nacos Discovery–服务治理

第三章 Nacos Discovery–服务治理

閱讀本文約花費: 12 (分鐘) 主要介绍了什么是服务治理,什么是nacos,以及nacos实战包括环境搭建,实现服务调用的负载均衡等相关。 先来思考一个问题 通过上一章的操作,我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址(ip,端口)等硬编码到了代码中,这种做法存在许多问题: 一旦服务提供者地址变化,就需要手工修改代码 一旦是多个服务提供者,无法实现负载均衡功能 一旦服务变得越来越多,人工维护调用关系困难 那么应该怎么解决呢, 这时候就需要通过注册中心动态的实现服务治理。 什么是服务治理 服务治理是微服务架构中最核心最基本的模块。用于实现各个微服务的自动化注册与发现。 服务注册: 在服务治理框架中,都会构建一个注册中心,每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单,服务注册中心需要以心跳的方式去监测清单中的服务是否可用,如果不可用,需要在服务清单中剔除不可用的服务。 **服务发现:**服务调用方向服务注册中心咨询服务,并获取所有服务的实例清单,实现对具体服务实例的访问。 通过上面的调用图会发现,除了微服务,还有一个组件是服务注册中心,它是微服务架构非常重要的一个组件,在微服务架构里主要起到了协调者的一个作用。注册中心一般包含如下几个功能: 1. 服务发现: **服务注册:**保存服务提供者和服务调用者的信息 **服务订阅:*…

Read More Read More

Scroll Up