|
|
51CTO旗下网站
|
|
移步端
创造专栏

宜信微服务架构落地及其形成|分享实录

副单体到SOA架构,副分布式服务化架构再到微服务架构,集团运用架构领域每一次技术架构的形成都会给企业带来更多的均值:任务解耦、能力复用、关怀点分离、联系效率提升、很快多变、很快交付、很快反馈等。

笔者:王佩华| 2019-12-31 10:33

主讲人介绍

王佩华:宜信科技中心基础研发部SIA微服务网关负责人

导读:副单体到SOA架构,副分布式服务化架构再到微服务架构,集团运用架构领域每一次技术架构的形成都会给企业带来更多的均值:任务解耦、能力复用、关怀点分离、联系效率提升、很快多变、很快交付、很快反馈等。此次分享主要介绍微服务架构的基础设施建设,及如何更好地劳动宜信实际工作和赋能业务。

分享大纲:

一、使用服务架构演进及微服务架构介绍

二、SpringCloud微服务生态系统介绍

三、宜信微服务架构和SIA网关的四种淘汰式

四、使用场景及典例分析

五、常见问题解答

PPT载入:https://pan.baidu.com/s/1uOFvCN0IlqXgNTIWqovZlw

分享实录

一、使用服务架构演进及微服务架构介绍

1.1 使用架构的形成历程

宜信微服务架构落地及其形成|分享实录(附视频)

使用服务架构一直处于不断演进的经过中, 上图通过对比5种比较主流的架构模式,展示应用架构的形成历程和浮动。

  • 单体架构(All in One) 在工作发展初期,为了迅速落地应用,满足客户需求,普通会使用All in One的单体架构。 单体架构的性状是:整整模块都耦合在一番进程里,系统完全封闭且很复杂,牵一发动全局。  
  • 竖井式架构(Vertical Application) 随着业务的增强,单体架构越来越臃肿,咱们对系统做了垂直化的拆分,使用架构进入第二阶段即竖井式架构。 竖井式架构,就是根据工作属性将一个大的单体拆分成一些不同之模块或子系统,子系统之间没有直接关系。 竖井式架构依然存在紧耦合的题材,系统也是完整封闭的,且存在大量之故伎重演代码拷贝及模块功能需大量重复造轮子的状况。
  • 单体架构和竖井式架构都是围绕web容器打包及配置之架构模式,随着业务的高效发展,渴求实现服务的高效迭代和飞跃交付,使用架构也由此形成为以劳动为骨干的架构模式。 主流的面向服务的架构模式有:RPC架构、ESB基本化架构和微服务架构。

  • RPC架构。 RPC架构在现行的使用体系中还是比较广泛的架构模式,租用于高并发场景,性能比较好。 Dubbo就是一番典型的RPC架构。 RPC架构也存在一些问题: 穿过共享分布式对象实现远程方法调用,如果在其中一个对象里添加一个属性,就会对共享对象的劳动者与顾客产生影响,故此RPC架构也是紧耦合的全封闭式,系统交互采用RPC个体TCP协和,劳务生产者和顾客存在强代码依赖,异构系统集成不谐和。  
  • ESB基本化架构。 ESB基本化架构实现了松耦合,依赖于ESB信息总线技术实现异构系统之消息交互和合并集中式架构管理,故此他虽然是面向服务的,但他实质上依旧是一番主导化的架构。 他优势在于: 基于WebService艺术,重量级的信息报道机制,咱们称之为“智能管道哑终端”,顶团队规模比较大、要贯彻异构系统集成时,他可以提供统一的解决方案和艺术实现方式,很快集成异构系统以外服务。 ESB基本化架构的题材也比较显著: 基本化架构难以满足灵活性的劳务迭代和需要交付。  
  • 微服务架构。 微服务架构实现了系统解耦和后续集成,有鲜明的劳务边界,零度相对ESB架构和风俗SOA架构来说更小,采用轻量级的报道机制交互,具备更强的扩展性和机动性,能够更灵活、更快响应业务变化。
  • 穿过上述对比,咱们不难发现,使用服务架构是在不断演进的,而且其形成背后存在一定的逻辑, 劳务架构的形成主要取决于以下2个维度: 

  • 工作维度, 艺术架构是由业务发展所处的时代和阶段决定的,艺术架构要能够消灭工作发展历程中的痛点。 在开展架构选型时,要求考虑这个架构是否能满足当前工作的急需,工作需求能否随着架构的形成实现总产值式的迭代。  
  • 艺术维度, 一边要满足非功能需求,有效业务迅猛跟上技术生态的上进; 一边出于商业的技艺考量,比如去IOE、 扮演V、 利用开源的技艺解决方案的急需,逐渐形成服务底层使用的生意软件的技艺隔离,满足业务迅猛交付。
  • 1.2 微服务架构的概念

    关于微服务的概念,此地引用ThoughtWorks首席经济学家Martin Fowler送出的叙说。

    宜信微服务架构落地及其形成|分享实录(附视频)

    其中以下特点值得特别注意:

  • 微服务架构是一种架构模式,倡议将单⼀应⽤先后划分成⼀组⼩的劳务。  
  • 劳务之间采用轻量级的通信机制。  
  • 劳务可以独立布置。  
  • 有道是尽量避免统⼀的、集中式的劳务管理体制。  
  • 现实的⼀个服务可以选择适宜的语⾔、⼯具对他行⾏构建。
  • Martin Fowler对于微服务架构的发表更偏向学术上的概念,没有给出明显的出生标准或标准,是不是 提供了部分构建微服务架构的规则。

    1)面向开发者和工作实现

  • 拆分成粒度小的劳务。  
  • 各自独立的经过实现服务运行隔离。  
  • 劳务运行通过轻量级的基于HTTP协和的RESTful API的通信机制进行。  
  • 劳务关注围绕业务领域之上构建。
  • 2)面向服务的付出和运维

  • 在劳动付出方式上,强调可独立布置。  
  • 支持去中心化的计划,劳务一般不需要集中化的治本。
  • 1.3 如何筛选微服务

    微服务架构模式有如此多之长处,那是不是全部的工作都要运用这种架构模式呢?又 该如何筛选微服务?

    宜信微服务架构落地及其形成|分享实录(附视频)

    左侧图中,横坐标代表系统复杂度、纵坐标代表开发生产力、蓝色线表示微服务架构、浅绿色线表示单体架构。由图可知, 顶项目复杂度较低时,单体架构的战斗力更高;随着项目复杂度越来越高,单体架构的战斗力逐渐降低,微服务架构的战斗力则明显增强。

    1)3种现象可以考虑采取微服务(Are you tall enough? )

  • 规模大,团组织超过10人口。  
  • 工作复杂度高,系统超过5个子模块。  
  • 要求长期形成,品种周期超过半年。
  • 2)其它因素筛选微服务

  • 硬件功能变化频繁,以快速迭代、缩短交付周期为主干的工作。  
  • 模块有独立的生命周期,微服务强调服务复用,调减重复造轮子,贯彻降成本增效。  
  • 有独立的隔离性需求和扩展性需求(容错)。  
  • 多极化的表面依赖。 比如Facade分立式场景,此后端系统采取统一的以外暴露的样式提供服务。
  • 1.4 如何拆分构建微服务

    辨认出哪些业务需求采取微服务架构模式下,要求决定 如何拆分和构建微服务。

    宜信微服务架构落地及其形成|分享实录(附视频)

    1)劳务拆分

    如何开展服务拆分,是在微服务过程中业务方经常会问到的题材。
    其实很多团队已经初步在做一些微服务化的上班,比如把大的水利拆分成不同之模块或子系统,这种对工作模块进行的常态划分,方便于已经形成了微服务改造的首要地拆分。
    上图是 DDD(天地驱动设计) 的支出模式,如果工作方案已经确定采用微服务的架构模式,在任何工程领域我们赞成于使用DDD分立式来对工作架构和劳务开展拆分。
    DDD是基于领域模型的建模而不是必发娱乐登录表驱动的建模,要求我们对工作领域有浓厚的考察,刺探服务的境界和上下文信息传递。
    康威定律 指出: 在微服务架构和计划系统组织,他产生之计划等价于组织间的关联结构。就是说微服务架构不仅是艺术上的形成,同时对利用技术之团队提出了要求,拆分的劳务是咱们和劳务之间的关联方式。

    2)微服务构建

    咱们采取微服务的12因子作为微服务建设之架构原则。 微服务的12因子也叫云原生12因子,他提供了一种工作上云或微服务改造的超级实践。根本介绍其中几个因子:

  • 谱代码 ,提议项目采用一份基准代码、多份部署。 品种在拆分时可能会存在多份基准代码,造成大量爆炸性的不同版本的编码共存的场面。 在开展微服务构建时,要求把集体服务和集体代码抽取出来,联合支撑不同版本的工作。  
  • 显式依赖 ,显式声明依赖关系。 对于 Java 先后,在 Gradle 或者Maven官方写明依赖关系。
  • 安排 ,在条件中存储配置。 根据目前的气氛容量决定采取什么样的配置文件。  
  • 此后端服务 ,把今后端服务当成一个附加资源。  
  • 构建、通告、运作的分别机制 ,强调服务和构建在运行时,不可以直接修改运行中的代码,而是需要通过构建发布流程统一公布。  
  • 产业化状态进程 ,以一个或多个现代化状态的经过运行应用。
  • 1.5 微服务架构2种建设思路

    微服务看起来非常好,但其实是要求一个艺术系统或平台体系来支撑的,如果没有这样一个劳动架构平台体系的振兴,不推荐使用微服务。

    宜信微服务架构落地及其形成|分享实录(附视频)

    微服务架构建设人均2种思路:SDK分立式、ServiceMesh分立式。

    1)SDK分立式

    突出代表是SpringCloud ,SpringCloud是基于SpringBoot的一整套实现微服务的框架。 SDK分立式的底色运行平台可以是PaaS平台,也得以是Kuberneters平台或Docker容器。

  • 优势: 面向应用和付出人员,研制化、协和支持灵活,相当完全自治的劳务状态,富有线下调试,对操作系统平台无依赖。  
  • 症结: 使用需引入额外SDK依托包,SDK自己占用内存及系统资源,对工作是侵入性的; 要求构建微服务基础设施做工作能力支撑; 要求采取SideCar分立式实现异构系统集成。
  • 2)ServiceMesh分立式

    Istio 是ServiceMesh分立式的杰出代表。 ServiceMesh分立式的得失与SDK分立式正好相反。

  • 优势: 不需要额外引入SDK依托包,对使用配套化侵入,且对Kubernetes原始友好支持。  
  • 症结: 布局比较复杂,对底层系统有稳定的依赖; 报道协议类型支持受限,要求依赖Mesh平台兼容。
  •  二、SpringCloud微服务生态系统介绍

    SpringCloud是基于SpringBoot开拓进取而来之一整套成熟的微服务架构解决方案。SpringCloud具有以下优势:

  • 面向开发者,以开发者为骨干,开发者生态友好。 
  • 以Java艺术栈为第一开发语言,代码可复用,微服务转型成本低。 
  • 基础设施完备,提供端到头的微服务架构解决方案。 
  • 有许多大厂做背书,如Pivital、Netflix,、alibaba等企业都是其生态和源代码贡献者,艺术经历过大范围商业应用的考验。
  • 2.1 SpringCloud的技艺生态

    SpringCloud自己也是一番逐渐形成的架构模式:最早是基于IOC/AOP的编程思想产生之;下一场在Spring的基础上发展出SpringBoot,基于注解的措施实现迅速的使用开发;新兴在SpringBoot的基础上开发出SpringCloud底层微服务构架。

    宜信微服务架构落地及其形成|分享实录(附视频)

    上图展示了SpringCloud的技艺生态, SpringCloud艺术栈包含了众多艺术模块,比如Ribbon、Zuul、Eureka、SpringCloud Stream等,该署艺术模块共同组成了SpringCloud生态圈, 为开发者提供丰富的微服务架构基础设施支撑。

    2.2 微服务和SpirngCloud架构的纷繁

    宜信微服务架构落地及其形成|分享实录(附视频)

    微服务和SpirngCloud的架构是比较复杂的,如配置管理、劳务注册与发现、API网关、打包部署调度、安全、劳务故障自愈、年产量控制和机动性伸缩等非功能需求,都是微服务要求包含的架构模块。上图中蓝色字表示SpirngCloud、Kubernetes等用来解决云原生和微服务架构问题的技艺方案。
    副图中得以看到微服务架构的纷繁, 要想实现一套微服务架构来支撑和交给业务,要求在底层封装很多基础组件,构建一套底层基础架构来隔离底层的非功能需求,成功让工作系统产品化感知、平滑地对外提供服务。

    三、宜信微服务架构和SIA网关的四种淘汰式

    SpringCloud提供的框架或基础设施是一番半成品,咱们在SpirngCloud的基础上进行了二次开发,空泛和包装了部分微服务架构的合同基础设施平台,不同之工作团队共享这些基础设施,降低技术学习和接入成本,让工作团队更注意于业务逻辑的贯彻,聚焦业务开发。

    3.1 宜信微服务架构

    宜信微服务架构落地及其形成|分享实录(附视频)

    上图所示为 宜信的微服务架构:

  • 微服务网关 ,sia-gateway采用了去中心化的网关接入方案。  
  • 元数据服务层 ,用Eureka-plus和sia-config对注册中心Eureka和安排中心做了提高与优化。  
  • 任务管理 ,基于微服务的思维,付出和开源了微服务任务调度平台SIA-TASK。  
  • 容器平台 ,贯彻了迅猛的无构建、布局和劳务编排。  
  • DevOps ,微服务的付出频率、速度比较快,要求有继承集成、接轨开发工具和手法来维护项目质量和劳务正常运转,对此我们有自研的UAVStack监督体系、电气化测试系统等工具链。
  • 3.2 SIA微服务网关架构

    宜信微服务架构落地及其形成|分享实录(附视频)

    分别其他的架构模式, 微服务架构里出现了一番重要的基础设施变化-增长了微服务网关模块。 网关主要 消灭之题材是:劳务拆分之下,每一个劳动粒度都比较小,劳务之间的交互会呈现网状的组织,要求一个聚合的兴奋点来聚合这些微劳动。
    故此我们在SpringCloud微服务架构的基础上二次开发出SIA微服务网关,如图所示,根本介绍其中的 2个中心模块:

  • 网关组 ,网关组里封装了两种网关: 同步网关和异步网关。  
  • OAM ,分立式网关管理平台,整整工作节点的生命周期管理都通过这个模块来开展。
  • 3.3 SIA微服务网关之4种淘汰式

    宜信微服务架构落地及其形成|分享实录(附视频)

    SIA微服务网关之4种淘汰式:同步托管式、同步注解式、异步托管式、异步注解式。

    1)同步托管式

    利用单一源码库进行代码管理,付出方式是容器交付,扮演中心化的计划。 脚下大部分生产条件和工作都使用同步托管模式。

  • 优点 网关交付对工作方完全透明; 只要在容器平台申请一个网关资源,就足以得到网关服务; 基于Filter付出运维简单,增量小。  
  • 症结 研制化不够强。
  • 2)同步注解式

    在跟业务团队对接时,咱们发现 有的是作业系统已经实现了部分奇异之工作逻辑,难以迁移到网关,故此我们采取一种比较兼容的诠释的措施去适应这些业务逻辑,在原来项目的基础上加一个注解,名将它们纳入到任何网关管理系统中来。 同步注解式是基于SpringCloud-Zuul 1贯彻的分布式微网关体系,管理工作方源码库,根据工作方环境进行交付。

  • 优点: 对项目的控制力比较强,工作团队独立运维,支持扩展定制化; 基于Filter付出运维简单,增量小。  
  • 气象 工作定制化场景比较多。 如果要加载初始化、加大资源,或对工作的Filter阻碍机制有定制化需求,都得以用同步注解模式。
  • SpringCloud和Zuul采用的下端技术是基于Servlet,他线程处理模型是一番请求对应一个点程,顶请求量过多,点程栈溢出,就会占用非常多之风源,导致网关无法提供额外的点程资源来处理新进来的呼吁。故此我们 利用了SpringCloud自研的SCG艺术方案。
    SpringCloud-Gateway基于Netty和反应式编程模式,利用收敛式的点程处理模型,只要用少数点程就得以处理高并发的话务量请求。脚下已经实现了基于SpringCloud-Gateway的异步模式, 顶同步模式在线上运行过程中出现资源透支的状况,就分选使用异步模式。 异步模式也分为2种:异步托管式、异步注解式。

    3)异步托管式

    穿过单一源码库进行代码管理,利用容器交付。重点采取场景是增量型, 如果工作多对高并发、高吞吐场景,提议使用异步托管式。

    4)异步注解式

    如果想在异步网关基础上做定制开发,可以运用异步注解的全封闭式。 
    网关的4种淘汰式来源于业务的急需: 为兼容业务已有逻辑演进出注解模式;顶出现性能瓶颈、能源浪费时,利用异步模式应对高并发流量。

    宜信微服务架构落地及其形成|分享实录(附视频)

    上图是网关测试环境的一个截图, 包括上述4种淘汰式。每一个小方格代表业务的一个网关组,方格中的小圆圈代表他属于哪一种网关。 工作系统在选择网关模式时要做一个判断:诉求是支持业务的高效集成,还是对流量有稳定要求。

    3.4 SIA微网关的骨干Feature

    宜信微服务架构落地及其形成|分享实录(附视频)

    如图将SIA微网关的骨干Feature人均2个范畴:

  • 数量面 ,承担数据包的拍卖逻辑。 路由转发、负载均衡、灰度发布、日志审计、熔断限流等都是副数量层面对流量进行管理。  
  • 控制面 ,承担服务粒度上的治本。 联合视图管理、多用户管理、登记中心、配置管理、路由组件绑定等是副左右层面来维护和保管服务。
  • 3.5 SIA微网关对微服务的生命周期管理

    微服务网关贯穿了整整微服务生命周期的治本。

    宜信微服务架构落地及其形成|分享实录(附视频)

    SIA微服务网关之效应包括:

  • Swagger UI、模块复用 对应服务文档中心模块的效应。  
  • 动态路由、共享能力 集中在分布式网关节点。  
  • 日志管理、管控组件 是网关Master提供的效应。
  • 各职能模块对应的生命周期:

  • 劳务文档中心 ,对应整个软件生命周期的早期开发和计划阶段,网关提供一个个联合的API挂图,前者和后台可以通过Swagger UI来联调开发。  
  • 分布式网关节点 ,在开发和布局阶段会涉及到部分共享能力的调度和运转。  
  • 网关Master ,在运维阶段通过行政化运维提高运维效率; 在管理方面,提供多少统计的效应,浮动数据报告用于管控。
  • SIA微服务网关作用于软件生命周期的各国阶段,穿过专业协同、工作测试/前者后端沟通、劳务模块复用、可视化管理、数量统计管控等实现业务的联合融合、降成本增效。

    3.6 总结:微服务架构与我方台&看台

    宜信微服务架构落地及其形成|分享实录(附视频)

    2016年,Gartner 通告了一番关于应用变化速率的报告《Pace-Layered Application Strategy》, 以应用变化速率为规范将工作应用分为三层:

  • SOI-敏态业务: 比如互联网业务,需要变更快,渴求快速迭代 、很快交付。  
  • SOR-稳态业务: 比如传统业务,改变周期⻓、扭转频率低、扭转成本高、扭转⻛险高。  
  • SOD-官方台工作: 齿轮匹配失衡,官方台就像是在起跳台与柜台之间添加的⼀组“变速⻮车轮”,名将前台与柜台的准确率进行匹配,提升⽤户响应力。
  • 官方台的对象是围绕业务组织开展可复用能力的遗传工程结合,援助业务落地实施、改建、试错、改装,提升组织效率,降低系统成本。
    官方台和微服务有什么关系呢? 微服务架构是面向开发的架构,有的是基础服务可以沉淀到微服务架构里,同时,微服务架构把我党台的力量快速释放出来,满足敏态业务迅猛变更的工作需求。

     四、使用场景及典例分析

    4.1 诠释&聚拢

    宜信微服务架构落地及其形成|分享实录(附视频)

    上图是路由管理里之一个截图,顶一个大的单体或不同之劳务中心对外提供统一服务时,可以 把劳动聚合到网关上 ;同时一个大型应用也得以 穿过网关分解成微服务。

    4.2 复用&现代化

    宜信微服务架构落地及其形成|分享实录(附视频)

    微服务架构中有许多非功能需求,或者说是艺术导向型的急需,包括日志管理、限流、蓝绿部署、本子管理等,可以 穿过组件的措施下沉到网关上,工作系统通过将服务与组件绑定实现对组件功能的复用。
    咱们还 提供了一番插件机制 ,顶业务有突出之急需, 可以根据她工作逻辑在网关上进行功能的最大化定制。

    4.3 API&契约

    宜信微服务架构落地及其形成|分享实录(附视频)

    在开发或前后端联调时, 内外端可以通过网关服务文档中心的Swagger UI效益模块访问之后端服务合同接口的剖析。
    只要在以后端服务之上加一个 Swagger诠释 网关就足以把整个对外暴露的劳务抓取出来,这相当于是一种 契约式的支出。

    4.4 容错&维护

    宜信微服务架构落地及其形成|分享实录(附视频)

    咱们对网关应用做了容错和维护机制,当然这也是SpringCloud自己自带的一个艺术模块, 咱们的容错机制是基于SpringCloud的Hystrix贯彻 的, 顶发现以后端服务合同请求一直在返回错误时,会开启熔断,避免由于一直发送错误请求导致雪崩的状况发生。
    除此之外,咱们还会 利用Guava限流的措施对劳动开展保护。 在大促或秒杀的面貌下,会有恢宏请求进来,这会儿会通过限流来维护服务的安居。

    4.5 监督&治理

    宜信微服务架构落地及其形成|分享实录(附视频)

    宜信微服务架构平台有一度很重大的效应是网关服务运行状态和今后端连接状态可观测, 提供了众多监控方面的效应组件,如图所示,可以统计当前呼吁的效率、劳务健康度。 
    预警方面重点介绍 网关拓扑图。 顶请求失败,眼前链路出现异常,穿过网关拓扑图可以快捷跟踪和判断业务系统哪个节点出现问题,下一场对有问题的兴奋点进行摘除或其它操作。
    咱们的网关运行在Docker平台上,Docker平台在出现问题或重启之后日志会丢,咱们的 日志系统会把日志归集,存储到ES官方,便于对历史日志溯源。

    4.6 统计&剖析

    宜信微服务架构落地及其形成|分享实录(附视频)

    网关中有一度组件叫 “监督统计” ,其一模块默认是不打开的,如果你想对请求做延时,或者想看请求的周密调用情况,可以通过组件管理中开拓这个组件,对容器的呼吁做统计和分析。监督统计组件会对目前呼吁的最大延迟、最小延迟、失败个数、平均延迟进行排序,一目了然。

    五、微服务化架构建设遇到的题材

    5.1 计划初期的题材

    1)如何隔离业务网关,同时有统一的治本视图?

    构建微服务网关初期,工作同事比较关注我们的工作网关和他人的网关是否存在耦合问题,她的工作请求是否会影响到我。 咱们选用去中心的网关设计方式,同时通过OAM贯彻对一切网关节点的联合管理。

    2)平台型系统建设初期是否要考虑同步异步网关融合?

    咱们的微服务网关是按照DDD天地驱动模式来建设之,没有把网关绑定在某一个奇异的技艺实现上,而是把他作为一个抽象封装来统一管理下端的兴奋点,如果换一种艺术实现也不会影响到前端业务的健康工作。 故此在架构建设初期要考虑清楚你的工作系统和今后端技术架构之间是否解耦。

    5.2 采用开源方案之题材

    3)开源系统本身的bug

    虽然每一种开源方案在开源之前都经过了长时间的考验,但其实依然可能生存bug,基于这些开源方案进行二次开发时仍可能遇到一些坑,咱们会不断对开源系统开展bug修复和作用增强。

    4)系统之性质问题

    Zuul自己存在性能瓶颈,顶出现性能问题时,咱们考虑是不是中心用点程收敛的全封闭式来提高网关的性质。

    5.3 上点生产运维方面的题材

    5)如何控制Eureka登记中心的CAP题材?

    在网关应用中会遇到Eureka的CAP题材,因为Eureka信息注册以可用性(Availability)优先,在经常性(Consistency)上相对较弱。 为解决这个题目,咱们基于Eureka的性状提供SynchSpeed劳务,如果工作需求保证状态一致性,可以开启这个服务。

    6)SpringCloud与SpirngBoot不同版本的兼容问题? K8S平台与微服务注册中心状态同步?

    这两个问题是指当云容器平台的状态发生改变,却没有及时通知到注册中心,导致服务在两个平台的状态不一致,这就要求做上下文关联系统(StakeHolder)的重组。

    【本文是51CTO专栏机构宜信技术必发娱乐登录的原创文章,微信公众号“宜信技术必发娱乐登录( id: CE_TECH)”】

    戳这里,瞧该作者更多好文

    【编纂推荐】

    1. 10个优质实践技巧,贯彻有效的微服务架构
    2. 为什么90%的“码农”做不了“架构师”?
    3. 苏宁砍价团高可用、高并发架构实践
    4. 腾讯万亿级Elasticsearch艺术解密
    5. 互联网架构,结果为什么需要配置中心?
    【义务编辑: 张燕妮 TEL:(010)68476606】

    点赞 0
  • 架构  运维  艺术
  • 分享:
    大家都在看
    猜你喜欢

  • <font id="3d377ae4"></font>