Browsed by
标签： 微服务

写了100多篇原创文章，我常用的在线工具网站推荐给大家！

写了100多篇原创文章，我常用的在线工具网站推荐给大家！

Comments 0 Comment  17 Views

閱讀本文約花費: 3 (分鐘)摘要 不知不觉写博客已经一年多了，累计写了100多篇原创文章，今天给大家分享下我经常使用的在线工具网站，希望对大家有所帮助！ Markdown Nice 支持自定义样式的在线Markdown编辑器，编辑完成后可以一键复制富文本到微信公众号、知乎和掘金等平台。多达17种主题，总有一种适合你的！平时用Typora写完文章以后，我都会用这个排版，然后复制到公众号，非常好用！ 地址：mdnice.com/ Process On 一款在线作图工具，支持流程图、思维导图、原型图、UML、网络拓扑图、组织结构图等。平时文章中的流程图和思维导图，我都是用这个工具画的！ 地址：www.processon.com/ draw.io 又一款在线作图工具，平时用来画画流程图还是很不错的，最大优点是可以将图片存储到不同的网络位置。 地址：www.draw.io/ 有道云笔记 文档管理，高效记录，它还有电脑客户端和手机端，使用方便。有个在线笔记工具还是很有必要的，比如平时搜索到的一些有用的文章，我会保存到笔记中去，方便以后查阅。平时有一些想学习的技术或者需要办理的事情我也会记录下来，毕竟好记性不如烂笔头。 地址：note.youdao.com/ Iconfont 阿里巴巴矢量图标库，可以根据关键字搜索的图标库。写过前端的朋友肯定很熟悉，需要图标的时候上去找就对了！还记得mall-…

Read More Read More

架构师必备技能：架构图的构图

架构师必备技能：架构图的构图

Comments 0 Comment  15 Views

閱讀本文約花費: 7 (分鐘)在做软件或应用解决方案的时候，一定会涉及到总体架构图或应用架构图的绘制，今天就谈下在架构图的绘制时候需要考虑的一些关键内容。 总体架构构图 对于总体架构沟通在类似智慧城市整体解决方案，企业总体IT架构解决方案中用的比较多。即不针对单个业务系统，而是面向整个行业或整个企业的IT整体架构解决方案。在这些图中，一般一个大的业务系统，类似CRM，ERP等也就是一个方框的位置。 这类总体架构重要的一个体现就是分层，一般还是底层的IaaS基础设施资源层，然后是中间的PaaS平台服务层，接着是上层的应用层。注意在当前微服务架构新模式下，上层的应用层本身又会拆分为中台层+上层的应用层。应用层在上面是门户层。 对于PaaS平台服务层，关键的内容还是技术平台，数据平台，集成平台等，技术平台本身又包括了应用托管平台和中间件资源池，传统的4A，流程平台，也包括了各类技术服务的提供。具体PaaS平台服务层要规划哪些内容，可以结合实际的项目需求来进行规划。 如果是对于物联网等项目，那么在资源层下面还有物联网感知层和网络层。 对于应用层，可以考虑对具体的业务系统进行归类或业务域划分，比如企业内的IT架构图，可以基于价值链或其他方式，按市场销售，产品研发，生产制造，客服服务，财务管理等业务域对业务系统进行归类。 对于总体架构图一般两边会规划类似技术标准体系，安全管控体系等相关内容。 …

Read More Read More

物联网2.0平台架构体系

物联网2.0平台架构体系

Comments 0 Comment  97 Views

閱讀本文約花費: 6 (分鐘)准确的来说，物联网1.0平台的单体应用架构没有互联网项目架构一说，传统的MVC开发模式，简单的小作坊操作流程，对于每个开发人员来说，只需要关注业务的功能模块实现而已。在1.0平台运营的半年时间里面，除了业务本身的需求爆炸性的增长，要求开发的迭代迅速，并且每次升级都不应该伤筋动骨，只是模块化的累加或者在原有的框架里面局部的更新，除了这些，我们还看到了1.0平台本身的基础性运营配套设施也迫切需要投入进来，以提高平台的运营效率，如日志平台，监控平台，调度平台，报表平台，甚至权限和单点登录也很需要，所以对于物联网2.0平台的整体规划以上的都应该包含在里面。 一 平台整体能力规划 主要将一些公共的东西全部从原有的业务层里面拆离出来，以平台化软件包的模式运营。 1. 统一调度平台在项目中很多业务会经常用到，但是1.0平台将调度工作和业务执行工作全部糅合在代码里面，造成大量的调度工作后期的维护非常不便，而且调度没法监控目前在运行的调度和距离下次需要执行的调度。统一调度平台可以解决这方面的问题，可以有效的通过管理界面来维护平台的所有调度工作，从设计角度简单来说，调度的工作归调度平台，业务的执行归个各自业务平台（微服务）。 2.统一接口平台主要解决前端应用系统通过统一接口平台获取数据，不直接与外部系统接口打交道。统一接口平台通过多种方式与外部系统联接获取数据并向各前端应…

Read More Read More

补习系列-springboot项目基础搭建课

补习系列-springboot项目基础搭建课

Comments 0 Comment  387 Views

閱讀本文約花費: 10 (分鐘)前言 springboot 最近火的不行，目前几乎已经是 spring 家族最耀眼的项目了。抛开微服务、技术社区这些推广因素不说，框架本身的确有非常多的优点。比如 更简化的配置，摒除了许多繁杂的xml配置(事实证明，越简单的东西越容易让人记住)； 内置Servlet容器，不再依赖外部环境 大量的starter模块，随手拈来 支持热部署 作为一名老程序员来说，仍然需要保持一个积极学习的态度。哎，简单点说就是少点伤感，认清现实。你曾经引以为傲的某某EE 技术已经被颠覆了，赶紧换车道 ….. 废话不多说，以下内容主要讲的是怎么利用springboot 这个脚手架搭建一个最精简的项目。其中几个模块会非常实用，这包括结构、配置、日志、部署.. 一、基础结构 springboot 项目仍然是使用maven 进行初始化及构建，下面是一个典型的结构： 目录文件 说明 pom.xml 依赖文件 src/main/java 代码目录 src/main/resources 配置目录，包含application.properties、log4j2.xml src/main/build 定义构建文件目录 src/test/java 测试代码 src/test/resources 测试配置 大致看一下就行了，不了解maven的话，点击这里先学习入门，项目的构建工具是…

Read More Read More

从基础设施到云原生应用，全方位解读阿里云原生新锐开源项目

从基础设施到云原生应用，全方位解读阿里云原生新锐开源项目

Comments 0 Comment  243 Views

閱讀本文約花費: 11 (分鐘)简介： 2020年11月19日，由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开，阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model（OAM）荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”，阿里云原生拿了一个分量十足的“大满贯”。 2020年11月19日，由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开，并正式揭晓了“开源杰出贡献人物”、“开源新锐项目”和“云原生行业落地典范”三大重量级奖项。在此前的入围赛中，仅“开源新锐项目”单项，阿里云原生就入围了10多个开源项目，在创新能力、社区成就和用户反馈等多项指标中一骑绝尘，占据了参评项目整体近五分之一。而在本次揭晓的“2020中国技术力量年度榜单”决赛结果中，最终阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model（OAM）荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”，阿里云原生拿了一个分量十足的“大满贯”。 在 2020 年，阿里不仅实现了双十一核心系统全面云原生化，一举成为全球规模最大、实力最硬核的云原生实践，并首次实现自研、开源、商业“三位一体…

Read More Read More

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

Comments 0 Comment  387 Views

閱讀本文約花費: 10 (分鐘)生产关系能否决定生产力？为什么这个社会需要管理？Kubernetes 是如此的成功，它的开源治理和技术架构是有着非常密切的关系的。 Tue Feb 6, 2018 | 3000 Words | 大约需要阅读 6 分钟 | | 康威定律（Conway’s Law） 随着信息技术的发展，以及现实的IT公司的成功，如Amazon、Netflix，以及云计算的普及，微服务的实践正在走向很多传统用户，然而，实施微服务的过程中，和DevOps的理念一样，人们发现并非仅仅是技术所能够解决的。还要涉及到组织架构。于是，伴随着微服务的发展，一位很少被人提及的科学家被推到了前端，也是被人忽视而尘封的科学家。 时间要拨回到1967年，Melvin Conway 以独特的视角观察到一个组织的组织结构会对其开发的系统有很大的影响。并撰写了“How Do Committees Invent” 这样一篇影响深远的论文，其中被人们广为知道的结论： 设计系统【这里也不仅仅是指信息系统】的组织，其产生的设计和架构等价于组织间的沟通结构。 该定律基于这样一个推理：为了能够让软件之间的模块相互作用，软件的撰写者们必须相互频繁的进行沟通，因此，系统的软件界面结构将会反映出打造此系统的组织的社会边界，要知道跨边界的沟通是比较困难的。Conway 定律的目的是试图说明这是蛮常见的社会学…

Read More Read More

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

Comments 0 Comment  313 Views

閱讀本文約花費: 16 (分鐘)微服务国内发展背景： 2014年，Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内，2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地，2016-2017年，微服务的概念被越来越多的人认可，带动了一大批公司以微服务和容器为核心开始技术架构的全面革新。 至今微服务已经历了两代发展，第一代以Spring Cloud为代表的微服务开发框架，该框架在微服务发展的前几年一度独领风骚，甚至在部分人群中成为微服务的代名词，但事实上该微服务框架并不是唯一实现微服务的方式；第二代微服务技术为服务网格（Service Mesh），它的出现解决了大部分开发人员在使用Spring Cloud中遇到的不足和痛点。 Service Mesh是如何解决这些问题的，又是何以赢得众多开发者的支持呢？笔者就这些问题给大家分享一篇以Istio为代表的第二代微服务实践。 一、微服务和Istio Service Mesh基本概念 服务网格是一个基础设施层，主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。 图1展示了服务网格的拓扑，当微服务数量增多达到几十上…

Read More Read More

使用Istio治理微服务入门

使用Istio治理微服务入门

Comments 0 Comment  262 Views

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄，服务治理难搞！ 一、微服务的“痛点” 微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。 微服务治理是头疼的事，也是微服务架构中的痛点。治理这个词有多元含义，很难下达一个精确定义，这里可以像小学二年级学生那样列出治理的诸多近义词：管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言，治理体现在以下诸多方面： 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说，微服务其实是一个“大系统”，要想将这个大系统全部落地，绝非易事，尤其是之前尚没有一种特别优雅的技术方案。多数方案（…

Read More Read More

kubernetes实践：Istio之策略与遥测

kubernetes实践：Istio之策略与遥测

Comments 0 Comment  311 Views

閱讀本文約花費: 9 (分鐘)一：Istio简介 1.Istio定义 一个用来连接，管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络，具备负载均衡，服务间认证和监控等功能。 而不需要改变任何服务代码。想要为服务增加对Istio的支持，只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。 2.为什么需要Istio 随着微服务出现，微服务的连接，管理和监控成为难题。Kubernetes可以处理多个容器的工作负载，但当涉及更复杂的需求时，需要像Istio这样的服务网格。 3.Istio的主要功能 a.流量管理(Pilot): 控制服务之间的流量和API调用的流向，使得调用更灵活可靠，并使网络在恶劣情况下更加健壮。 b.可观察性： 通过集成zipkin等服务，快速了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。 c.策略执行(mixer): 将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 d.服务身份和安全(Istio-auth)： 为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。 4.Envoy架构 a.svcA服务作为客户端点用服务端svcB，svc…

Read More Read More

微服务架构下的分布式限流方案全解析

微服务架构下的分布式限流方案全解析

Comments 0 Comment  338 Views

閱讀本文約花費: 9 (分鐘)1.微服务限流 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存的目的是提升系统访问速度和增大系统能处理的容量，而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开，而有些场景并不能用缓存和降级来解决，比如稀缺资源、数据库的写操作、频繁的复杂查询，因此需有一种手段来限制这些场景的请求量，即限流。 比如当我们设计了一个函数，准备上线，这时候这个函数会消耗一些资源，处理上限是1秒服务3000个QPS，但如果实际情况遇到高于3000的QPS该如何解决呢？ 所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率就可以拒绝服务、等待、降级。 学习如何去实现一个分布式限流框架，首先，我们需要去了解最基本的两种限流算法。 2.限流算法 2.1漏桶算法 漏桶算法思路很简单，水（也就是请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。示意图（来源网络）如下： 2.2令牌桶算法 令牌桶算法和漏桶算法效果一样但方向相反的算法，更加容易理解。随着时间流逝，系统会按恒定1/QPS时间间隔（如果QPS=100，则间隔是10ms）往桶里加入令牌（…

Read More Read More

SpringCloud-Ribbon[入门案例]

SpringCloud-Ribbon[入门案例]

Comments 0 Comment  214 Views

閱讀本文約花費: 4 (分鐘)一、 Ribbon 在微服务中的作用 1 什么是 Ribbon Ribbon 是一个基于 Http 和 TCP 的客服端负载均衡工具，它是基于 Netflix Ribbon 实现的。 它不像 spring cloud 服务注册中心、配置中心、API 网关那样独立部署，但是它几乎存在于每个 spring cloud 微服务中。包括 feign 提供的声明式服务调用也是基于该 Ribbon实现的。 ribbon 默认提供很多种负载均衡算法，例如 轮询、随机 等等。甚至包含自定义的负载均衡算法。 2 Ribbon 解决了什么问题 他解决并提供了微服务的负载均衡的问题。 二、 集中式与进程内负载均衡的区别 1 负载均衡解决方案的分类 目前业界主流的负载均衡方案可分成两类： 第一类：集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件，如 F5, 也可以是软件，如 nginx), 由该设施负责把 访问请求 通过某种策略转发至 provider； 第二类：进程内负载均衡，将负载均衡逻辑集成到 consumer，consumer 从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者，它只是一个类库，集成于 consumer 进程，consumer 通过它…

Read More Read More

6种微服务RPC框架，你知道几个？

6种微服务RPC框架，你知道几个？

Comments 0 Comment  221 Views

閱讀本文約花費: 7 (分鐘)跟语言平台绑定的开源 RPC 框架主要有下面几种。 Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。 Motan：微博内部使用的 RPC 框架，于 2016 年对外开源，仅支持 Java 语言。 Tars：腾讯内部使用的 RPC 框架，于 2017 年对外开源，仅支持 C++ 语言。 Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言 而跨语言平台的开源 RPC 框架主要有以下几种。 gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。 Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一，支持多种语言。 如果你的业务场景仅仅局限于一种语言的话，可以选择跟语言绑定的 RPC 框架中的一种； 如果涉及多个语言平台之间的相互调用，就应该选择跨语言平台的 RPC 框架。 RPC 框架，它们具体有何区别？ 1. Dubbo 先来聊聊 Dubbo，Dubbo 可以说是国内开源最早的 RPC 框架了，目前只支持 Java 语言，它的架构可以用下面这张图展示。 从图中你能看到，Dubbo 的架构主要包含四…

Read More Read More

深入解读Service Mesh背后的技术细节

深入解读Service Mesh背后的技术细节

Comments 0 Comment  189 Views

閱讀本文約花費: 14 (分鐘)一、Service Mesh是Kubernetes支撑微服务能力拼图的最后一块 在上一篇文章为什么 kubernetes 天然适合微服务中我们提到，Kubernetes是一个奇葩所在，他的组件复杂，概念复杂，在没有实施微服务之前，你可能会觉得为什么Kubernetes要设计的这么复杂，但是一旦你要实施微服务，你会发现Kubernetes中的所有概念，都是有用的。 在我们微服务设计的是个要点中，我们会发现Kubernetes都能够有相应的组件和概念，提供相应的支持。 其中最后的一块拼图就是服务发现，与熔断限流降级。 众所周知，Kubernetes的服务发现是通过Service来实现的，服务之间的转发是通过kube-proxy下发iptables规则来实现的，这个只能实现最基本的服务发现和转发能力，不能满足高并发应用下的高级的服务特性，比较SpringCloud和Dubbo有一定的差距，于是Service Mesh诞生了，他期望讲熔断，限流，降级等特性，从应用层，下沉到基础设施层去实现，从而使得Kubernetes和容器全面接管微服务。 二、以Istio为例讲述Service Mesh中的技术关键点 就如SDN一样，Service Mesh将服务请求的转发分为控制面和数据面，因而分析他，也是从数据面先分析转发的能力，然后再分析控制面如何下发命令。今天这篇…

Read More Read More

云原生架构概述

云原生架构概述

Comments 0 Comment  245 Views

閱讀本文約花費: 9 (分鐘)1. 什么是云原生 1.1 CNCF组织 在讲云原生之前，我们先了解一下CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软。思科等巨头。 目前CNCF所托管的应用已达14个，下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。 1.2 云原生 CNCF给出了云原生应用的三大特征： 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。 动态管理：通过集中式的编排调度系统来动态的管理和调度。 面向微服务：明确服务间的依赖，互相解耦。 云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。 这边引用网上关于云原生所需要的能力和特征总结，如下图。 云原生所需要的能力和特征 1.3 The Twelve Factors 12-Factors经常被直译为12要素，也被称为12原则，12原则由公有云PaaS的先驱Heroku于2012年提出，目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下： 基准代码 显式声明依赖关…

Read More Read More

蚂蚁金服 Service Mesh 实践探索

蚂蚁金服 Service Mesh 实践探索

Comments 0 Comment  228 Views

閱讀本文約花費: 50 (分鐘)摘要 在勇敢的选择了Service Mesh作为未来技术方向之后，蚂蚁金服率先开始了Service Mesh大规模落地探索。在此过程中，我们遇到很多问题，面临各种挑战，也有了一些思路和方法。今天我们将这些实践分享出来，并结合我们开源的SOFAMesh项目，和大家一起探讨：如何更好的将Service Mesh这样的新兴技术落地于实际生产环境。 大家好，我是来自蚂蚁金服中间件团队的敖小剑，目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人，是 Service Mesh 技术在国内最早的布道师。我今天给大家带来的主题是”长路漫漫踏歌而行：蚂蚁金服Service Mesh实践探索”。 今天我们的内容不是继续做 Service Mesh 的布道，今年要好好讲一讲实践。所以今天我不会像去年那样给大家详细解释 Service Mesh 是什么，能做什么，有什么优势。而是结合过去一年中蚂蚁金服的实践经验，结合蚂蚁金服的 SOFAMesh 产品，帮助大家更深刻的理解 Service Mesh 技术。 在开始今天的内容分享之前，我们先来热个身，温习一下去年的内容。去年我是来布道的，而布道的核心内容就是告诉大家：Service Mesh 是什么？ 为了帮忙大家回答，我给出一个提示图片，了解 Service M…

Read More Read More

Service Mesh (服务网格) 入门

Service Mesh (服务网格) 入门

Comments 0 Comment  191 Views

閱讀本文約花費: 11 (分鐘)现在最火的后端架构无疑是微服务了，微服务将之前的单体应用拆分成了许多独立的服务应用，每个微服务都是独立的。 微服务基本组件包括服务注册和发现、服务通信和治理、故障熔断恢复、配置、安全、监控等等，这些微服务组件和功能在业界已经深入人心，在各大互联网公司开花结果，业界知名开源的微服务框架有 Netflix OSS、Spring Cloud 及其国内的阿里 Dubbo 等等，各种框架百花齐放。 微服务好处自然很多，但是随着应用的越来越大，微服务暴露出来的问题也就随之而来了，微服务越来越多，管理越来越麻烦。特别是要你部署一套新环境的时候，随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。 当然随着微服务的不断发展，微服务的生态的不断完善，新的微服务框架 Service Mesh 的出现就是为了解决这一系列问题。 什么是 Service Mesh Service Mesh 是一个非常新的名词，最早是 2016 年由开发 Linkerd 的 Buoyant 公司提出的，伴随着 Linkerd 的传入，Service Mesh 的概念也慢慢进入国内技术社区。 Service Mesh 是一个基础设施层，其独立运行在应用服务之外，提供应用服务之间安全、可靠、高效的通信，并为服务通信实现了微服务运行所需的基本组件功能，包括服务注册发现、负载均…

Read More Read More

Scroll Up