- 综合排序
- 最热优先
- 最新优先
- 来自专栏全栈学习之路
基于SpringBoot的微服务架构与K8S容器部署实践
而大部分交易，发生在上班、午休以及下午3点左右（下午茶）的时间段内。 由于涉及到客户业务细节，这里对业务架构就不做详细说明了。 技术架构 这个案例中采用了基于SpringBoot的微服务架构。 结合企业自身的基础架构设施，进行K8S容器化部署，并采用Kong API Gateway对各业务中台暴露的API接口进行统一管理。 Kong具有以下一些特性，能够很好地满足大型组织对于服务网关的需求： 开源（本案例中使用的是Kong的企业版，提供了原厂服务） 亚毫秒级的响应延迟，得益于基于Nginx与OpenResty带来的超高性能 DEVOPS与K8S容器化部署 ####DEVOPS流水线 本案例中，通过基于jenkins的CICD平台，将应用代码从github代码库获取，使用gradle进行构建（前端使用npm构建），通过dockerfile Dynatrace Dynatrace可能是目前最优秀的应用性能管理工具(APM)，它既能监控基础设施如服务器，K8S容器，又能自动发现并监控在容器内运行的动态微服务，了解它们如何执行、相互之间如何通信
97411编辑于 2024-06-18 - 来自专栏禁心尽力
基于服务的SOA架构_后续篇
昨天简单介绍了一下本人在近期开发过的一个电商购物平台的架构流程和一些技术说明；今天将详细总结一下在项目中用到的各个架构技术的环境部署和细节，希望能够帮到大家，如有瑕疵，请各位大神指正。 一：详谈服务治理的核心框架之Dubbo及注册中心zookeeper 首先说说Dubbo这个框架吧，接触这个框架是在去年的年底，当时我们公司的架构师震哥赏了我一点关于架构方面的资料，我看了几天感觉挺对它们感冒的 ，所以就想着学学架构，哪天当当架构师，呵呵，这只是个近期目标，好了，还是吹吹主角dubbo吧。 Dubbo它是阿里巴巴出品的开源的分布式框架，它最大的特点是可以用分层的架构，使表现层和业务层实现解耦合。 最后赠送几张我们项目的总体架构流程图及模块分析图，可能有点不清晰，大家就将就瞅瞅，莫怪。【其他技术架构的分享后期还会更新，希望大家能够支持，谢谢】 ? ?
822100发布于 2018-01-24 - 来自专栏Python中文社区
基于Sanic的微服务基础架构
正是结合这些优点, 以Sanic为基础，集成多个流行的库来搭建微服务。 Sanic框架是和Flask相似的异步协程框架，简单轻量，并且性能很高。 本项目就是以Sanic为基础搭建的微服务框架。 sanic使用uvloop异步驱动，uvloop基于libuv使用Cython编写，性能比nodejs还要高。 不使用ORM做数据库操作，一个原因是性能，ORM会有性能的损耗，并且无法使用asyncpg高性能库。另一个是单个微服务是很简单的，表结构不会很复杂，简单的SQL语句就可以处理来，没必要引入ORM。 ，对客户端进行了简单的封装，用于微服务之间访问。 Opentracing跟踪每一个请求，记录请求所经过的每一个微服务，以链条的方式串联起来，对分析微服务的性能瓶颈至关重要。 使用opentracing框架，但是在输出时转换成zipkin格式。
4K70发布于 2018-03-26 - 来自专栏JAVA烂猪皮
基于 Docker 的微服务架构实践
本文来自作者 未闻 在 GitChat 分享的{基于 Docker 的微服务架构实践} 前言 基于 Docker 的容器技术是在2015年的时候开始接触的，两年多的时间，作为一名 Docker 的 DevOps 如果编排技术使用的 k8n，可以用 k8n 的一整套 Docker 微服务方案，对 k8n 感兴趣的可以阅读下Kubernetes 架构设计与核心原理。 目前可以在GCE、vShpere、CoreOS、OpenShift、Azure等平台使用k8s。国内目前Aliyun也提供了基于k8s的服务治理平台。 如果是基于物理机、虚拟机搭建的Docker集群的话，也可以直接部署、运行k8s。在微服务的集群环境下，Kubernetes可以很方便管理跨机器的微服务容器实例。 目前k8s基本是公认的最强大开源服务治理技术之一。其主要提供以下功能： 自动化对基于Docker对服务实例进行部署和复制 以集群的方式运行，可以管理跨机器的容器，以及滚动升级、存储编排。
2.8K31发布于 2018-08-03 - 来自专栏超级架构师
「微服务架构」基于NGINX的三种微服务参考架构
我们还认识到，实现微服务有许多不同的方法，其中许多方法都是新颖的，并且特定于各个开发团队的需求。我们认为需要使用模型来使公司更容易开发和交付自己的基于微服务的应用程序。 考虑到这一切，NGINX专业服务部门正在开发NGINX微服务参考架构（MRA） - 一组可用于创建自己的微服务应用程序的模型。 我们构建此参考架构的目标有三个： 为客户和行业提供随时可用的蓝图，用于构建基于微服务的系统，加速和改进开发 创建用于测试NGINX和NGINX Plus中新功能的平台，无论是内部开发还是外部开发，分布在产品核心中或作为动态模块 为了帮助我们了解合作伙伴系统和组件，我们可以从整体上了解微服务生态系统 微服务参考架构也是NGINX客户专业服务产品的重要组成部分。 微服务参考架构概述 我们正在构建参考架构以符合Twelve-Factor App的原则。这些服务设计为轻量级，短暂的和无状态的。
2K10发布于 2019-08-21 - 来自专栏阶梯计划
基于k8s+docker的SDN架构
系统的基础设施是可靠的（基于这一假设进行软件设计） 2 架构设计 2.1 逻辑架构 [逻辑架构图] 总体逻辑架构在k8s+docker的基础上分为“三纵”、“四横”。 其中公共服务和业务服务都属于控制器自身的服务，也部署在同一个k8s集群中；而三方服务可以是控制器独占的服务也可以是与其它系统共享的服务，部署形式也不局限，只需要服务间访问可达。 ：持久化存储（这里的外特指独立于k8s集群外的服务器），建议是独立的存储服务器。 2.4 运行架构 保持单容器单进程的设计，利用k8s的特性，可以帮助我们监控服务进程状态，并且当服务down掉后由k8s重新拉起容器。 2.5 物理架构 控制器系统是基于k8s+docker的，所以可以认为系统部署的基础设施为k8s集群。 k8s集群天然具备可伸缩性，因此控制器系统的扩缩容在这不是一个复杂问题，不再赘述。
1.9K21发布于 2020-08-16 - 来自专栏无敌码农
基于SpringCloud的微服务架构演变史？
经过一系列的重构+扩展，整个系统架构最终形成了以app为中心的一套微服务软件系统，结构如下： ? 到这里，整个软件系统就基于SpringCloud初步完成了微服务体系的拆分。 另外在基于SpringCloud的架构体系中，提供了配置中心（ConfigServer）来帮助各个微服务管理配置文件，而原本的api服务，随着各个功能的抽离，逐步演变成前置网关服务了。 难道基于SpringCloud的微服务体系中的应用服务都是单节点在提供服务，哪怕即使部署了多个服务节点？ 另外一方面也需要推进容器化（Docker/Docker Swarm/k8s）策略，这样才能快速对服务节点进行伸缩，这也是微服务体系下的必然要求。 后记 基于SpringCloud的微服务架构体系，通过集成各种开源组件来为整个体系服务支持，但是在负载均衡、熔断、流量控制的方面需要对服务消费端的业务进程进行侵入。
45410发布于 2019-07-31 - 来自专栏DevOps时代的专栏
基于DevOps、微服务以及k8s的高可用架构探索与实现
前言 本文给大家分享的题目是《基于DevOps、微服务以及K8S的高可用架构探索与实现》。 K8S是用什么样的方式来保证它的高可用性，首先有三个重要的点： 第一点，K8S是以容器化为基础的，运行在它上面的应该是一些容器，以容器形式存在的这些服务，K8S 平台保证了这些服务它本身是可用的。 第二点，我们保证K8S本身是可用的，因为K8S保证它的集群运行在这之上的服务是ok的，但是同时，怎样才能保证K8S它也是高可用的，消除这些单点我们也会说到这些。 这是一个很简单的例子，我们说整体的做一主多从的K8S架构的话，可以看出，这就是简单的K8S的构成。K8S可以做成一主多从，同时我们的ETCD使用集群的方式来保证它的服务OK。 使用了Kubernetes这种方式后，就会更加灵活，使我们的服务专注于服务的架构开发。 即使是这样，我们依然有很多的东西需要考虑，我们为什么进行微服务的设计和架构，这有很多很多的痛点。
1.8K91发布于 2018-02-02 - 来自专栏对线JAVA面试
基于Spring Cloud的微服务架构分析
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。 目前的网络架构是每个主机都有一个独立的IP地址，那么服务发现基本上都是通过某种方式获取到服务所部署的IP地址。 在Go生态中，还可以选择基于etcd作为注册中心，etcd是由CoreOS团队维护的、高可用分布式键值存储数据库，可用于为集群提供配置和服务发现功能，Google开源的容器管理工具Kuberbetes就是基于 Eureka：云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。 的微服务架构分析/
66110编辑于 2022-10-27 - 来自专栏纯洁的微笑
基于SpringCloud的微服务架构演变史？
经过一系列的重构+扩展，整个系统架构最终形成了以app为中心的一套微服务软件系统，结构如下： ? 到这里，整个软件系统就基于SpringCloud初步完成了微服务体系的拆分。 另外在基于SpringCloud的架构体系中，提供了配置中心（ConfigServer）来帮助各个微服务管理配置文件，而原本的api服务，随着各个功能的抽离，逐步演变成前置网关服务了。 难道基于SpringCloud的微服务体系中的应用服务都是单节点在提供服务，哪怕即使部署了多个服务节点？ 另外一方面也需要推进容器化（Docker/Docker Swarm/k8s）策略，这样才能快速对服务节点进行伸缩，这也是微服务体系下的必然要求。 后记 基于SpringCloud的微服务架构体系，通过集成各种开源组件来为整个体系服务支持，但是在负载均衡、熔断、流量控制的方面需要对服务消费端的业务进程进行侵入。
55210发布于 2019-09-05 - 来自专栏DevOps时代的专栏
基于 DevOps、微服务以及 k8s 的高可用架构探索与实现
业务的弹性扩容也同时会对高可用性的架构造成影响，在实践中，我们结合微服务/K8S/DevOps 这三架马车进行了微服务的容器化的实践之路。 ， 根据其定义，RTO/RPO与灾难恢复能力等级的关系具体如下所示： 高可用性设计的策略 冗余 服务多重化 节点多重化 两地三中心 … K8S + 微服务 + DevOps 在具体的实践中，将目标聚焦到 K8S/微服务/DevOps这三个角度，这三架马车各司其职，使得容器化的微服务落地更加顺畅。 kubernetes 上运行，依靠着 k8s 的 RC/deployment/DaemonSet 等机制，保证服务的高可用性。 ，则能保障动态弹性扩容机制的实现，整体使得基于容器化的微服务的架构具有更高的可用性。
1.4K32发布于 2020-10-26 - 来自专栏架构师专栏
基于 Spring Cloud 完整的微服务架构实战
基于 Spring Cloud 完整的微服务架构实战 本项目是一个基于 Spring Boot、Spring Cloud、Spring Oauth2 和 Spring Cloud Netflix 等框架构建的微服务项目 Eureka - 云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。 Spring Cloud OAuth2 - 基于 Spring Security 和 OAuth2 的安全工具包，为你的应用程序添加安全控制。 应用架构 该项目包含 8 个服务 registry - 服务注册与发现 config - 外部配置 monitor - 监控 zipkin - 分布式跟踪 gateway - 代理所有微服务的接口网关 auth-service - OAuth2 认证服务 svca-service - 业务服务A svcb-service - 业务服务B 体系架构 ?
3.2K80发布于 2018-02-09 - 来自专栏搜云库技术团队
基于SpringCloud的微服务架构分析，神仙框架！
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。 目前的网络架构是每个主机都有一个独立的IP地址，那么服务发现基本上都是通过某种方式获取到服务所部署的IP地址。 就是基于 Etcd 的。 Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。 架构分析 一个完整的Spring Cloud的分布式架构 Spring Cloud - Nacos与Eureka区别及如何选型 各大微服务注册中心简单对比：ZooKeeper、Eureka、Consul
1.8K10发布于 2021-10-20 - 来自专栏EAWorld
基于微服务架构的技术实践（附PPT）
大家好，今天分享的是“基于微服务架构的技术实践”，标题有点土，希望内容对大家有用。 · · · 微服务架构实践 回到今天的主体第二部分： 包括了技术和架构参考，平台主要架构设计，以及关键的模块设计。 基于上述的参考等，我们验证过上述的技术栈，用于支撑微服务架构，当然这里面已经有不少被我们放弃了，上图是从对象类型（横向）和功能要求（纵向）给技术做了一些罗列，也是我们平台使用的开源图谱，大家有兴趣可基于某几个来探讨 思考2：设计原则现在人人都会提，但微服务架构里，我觉得最重要的几个原则是这些： 隔离失败：微服务架构下，相互间的通信越来越多，不像单块架构那样，要坏一起坏，如何不受别人影响，以及自己不破坏别人，是要考虑的重点 关键3：微服务伸缩与漂移，上图里万年不变的公式。以漂移为例子，漂移有很多触发可能，有因为故障的，有基于优化考虑的，像优化这种，就要求定义很多维度，结合对微服务的监控打分加权。
7.7K100发布于 2018-04-02 - 来自专栏服务端技术杂谈
基于Service Mesh构建更现代的服务架构
当服务端部署的是单体系统的时候，我们只需要在负载均衡器之后对应用部署多个单体实例。随着系统一步步抽取解耦成很多微服务，就需要将整个运行架构的某些方面进行智能化升级。 控制面 控制面负责做服务发现，服务路由管理，请求度量等。 集合K8s 我们可以将每个服务器上的服务实例提供一个数据平面，也叫sidecar。 同时数据面板收集的数据会上报到控制面板。控制面板仅用来提供配置，获取数据指标，其不会出现在一个请求路径上。 事件驱动架构 微服务之间的通信不是唯一的通信方式，还有一种基于事件的体系架构可以创建他们。 在实际情况来说，我们需要基于网络请求，判断哪些延迟是正常的，哪些是不正常的，如果不正常就必须确保系统的最终一致性，并以此为前提构建客户端。 service mesh的实现也不一定需要k8s，但service mesh理念可以应用于任何平台。k8s可以让我们大规模运行微服务，不同服务可以用不同语言开发，这也是微服务的优势之一。
66330发布于 2019-11-19 - 来自专栏架构专栏
基于 Spring Cloud 完整的微服务架构实战
image.png 前言 本文介绍了技术栈，应用架构，体系架构，应用组件，怎么启动项目，以及相关的项目预览，介绍较为详细，详情请看下文。 Eureka - 云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。 Spring Cloud OAuth2 - 基于 Spring Security 和 OAuth2 的安全工具包，为你的应用程序添加安全控制。 二、应用架构 该项目包含 8 个服务 registry - 服务注册与发现 config - 外部配置 monitor - 监控 zipkin - 分布式跟踪 gateway - 代理所有微服务的接口网关 体系架构 2.
1.3K00发布于 2020-04-26 - 来自专栏程序猿DD
如何基于DDD构建微服务架构
子域：对于领域进行不同维度切分的相对内聚的子系统单元。 分层架构：通过分层架构将业务域和技术逻辑域隔离。 服务：服务通常是领域对象的调用方，用来协调领域对象完成指定业务逻辑职责。 服务拆分的依据 高内聚、低耦合是服务拆分的主要依据，下面我们列举一些常用的服务拆分策略，了解如何对单体架构进行拆分。 根据技术边界划分服务：对于产品类型的服务使用技术能力划分服务边界，前后端分离架构就是通过技术栈划分服务边界的典型架构模式。 分层架构设计 领域驱动设计遵循“关注点分离”原则，将技术实现逻辑封装在基础设施层；将业务逻辑封装在领域层，尽量使领域层代码与其他层技术细节分割开来；将应用层作为黏合剂，实现前两者的协作；同时UI层可以基于 微服务架构模式 微服务架构是强调细粒度、单一职责的架构模式。微服务架构更关注的是系统的非功能需求：质量属性、演进能力、扩展性、观测性、软件交付效率等。
81010发布于 2021-08-09 - 来自专栏深度学习与python
如何基于DDD构建微服务架构
子域：对于领域进行不同维度切分的相对内聚的子系统单元。 分层架构：通过分层架构将业务域和技术逻辑域隔离。 服务：服务通常是领域对象的调用方，用来协调领域对象完成指定业务逻辑职责。 根据技术边界划分服务：对于产品类型的服务使用技术能力划分服务边界，前后端分离架构就是通过技术栈划分服务边界的典型架构模式。 分层架构设计 领域驱动设计遵循“关注点分离”原则，将技术实现逻辑封装在基础设施层；将业务逻辑封装在领域层，尽量使领域层代码与其他层技术细节分割开来；将应用层作为黏合剂，实现前两者的协作；同时 UI 层可以基于 微服务架构模式 微服务架构是强调细粒度、单一职责的架构模式。微服务架构更关注的是系统的非功能需求：质量属性、演进能力、扩展性、观测性、软件交付效率等。 《微服务架构深度解析：原理、实践与进阶》 王佩华 著 微服务架构领域集大成之作 国内鲜有的微服务详解图书 本书从微服务架构的设计理念和方法论切入，从不同角度全面介绍微服务特性、使用场景、组织流程、构建交互
93410编辑于 2023-04-01 - 来自专栏腾讯云容器服务团队的专栏
华尔街见闻：基于腾讯云容器服务的微服务架构实践
云服务商成本 由于架构落后于需要，我们不得不用硬件弥补性能上的问题，导致云服务器成本不断增加。 三.华尔街见闻微服务架构设计 因此，在2016年11月至2017年3月，我们采用微服务架构启动重构，尝试解决一部分上述问题，在伸缩性上能以服务为单位进行拓容，同时，这一设计会在某些方面增大我们的开发成本和运维成本 服务端渲染 主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。 CI任务中的test->build->docker->deploy流程 五.云平台的选择 最终我们选择了腾讯云的容器服务，主要基于以下几点考虑： 腾讯云的容器服务是在腾讯云的iaas 上为每个用户构建容器集群，他们提供的微服务架构和持续集成与交付的应用场景基本满足了我们的述求。
3.7K00发布于 2017-05-09 - 来自专栏禁心尽力
互联网项目架构之基于服务的分布式架构
随着互联网电商项目的发展，越来越多的购物平台等都使用SOA分布式来作为系统主要架构。为什么有那么多的电商项目都选择SOA作为系统架构呢？ 这肯定是存在一定原因的，因为电商行业的项目它大概存在以下特点：分布式、高并发、高可用、集群、负载均衡、海量数据、系统安全等一系列问题都需要解决，那么我所了解的SOA分布式架构它正好基本能很好的解决这些问题 一：首先说说项目总体架构的流程 1、该项目采用SOA分布式架构，在此基础上我们又实现了面向服务的思想，中间件使用阿里巴巴出品的Dubbo服务治理的核心框架来管理整个系统的服务，并且选择zookeeper 来作为注册中心； 2、大家都知道，一个电商项目是无法避免如何处理海量图片资源的问题，所以这里由使用一款用C语言开发的开源分布式文件系统FastDFS作为图片服务器，专门用于存储系统中所有的商品图片 ，广告图片等资源，并且通过Nginx反向服务器来访问图片服务器上的资源； 3、接着说说商品搜索功能这块的架构，这里我们将在Linux系统上搭建了solr集群并实现了集群分片，安装了IKAnalyzer
1.5K100发布于 2018-01-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号