- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构师之路
微服务架构多“微”才合适？
）耦合 （4）SQL质量得不到保障，业务相互影响 （5）数据库耦合 “服务化”是一个很好的解决上述痛点的方案。 二、互联网微服务架构多“微”才适合 大家也都认可，随着数据量、流量、业务复杂度的提升，服务化架构是架构演进中的必由之路，今天要讨论的话题是：微服务架构多“微”才合适？ 垂直拆分是个好的方案，将子业务一个个拆出来，那么微信的服务化架构或许会变成这个样子： ? 总的来说，细粒度拆分的优点有： （1）服务都能够独立部署 （2）扩容和缩容方便，有利于提高资源利用率 （3）拆得越细，耦合相对会减小 （4）拆得越细，容错相对会更好，一个服务出问题不影响其他服务 （5） 扩展性更好 （6）… 细粒度拆分的不足也很明显： （1）拆得越细，系统越复杂 （2）系统之间的依赖关系也更复杂 （3）运维复杂度提升 （4）监控更加复杂 （5）出问题时定位问题更难 （6）… 关于微服务架构的
1.7K61发布于 2018-03-01 - 来自专栏一道题做一宿
基于Webpack5实现微前端架构
前言 最近这段时间微前端这个概念越来越被提及，它采用了微服务的相关理念，我们可以把一个应用拆分成多个可以互不依赖可以独立开发并单独部署的模块，然后在运行时把它们组合成一个完整的App。 从Webpack5开始，已经内置了对微前端开发的支持，它们提供了一个新的功能叫Module Federation（我也不知道该怎么翻译这个术语会比较恰当），提供了足够的能力来让我们实现微前端开发。 我们会实现一个简单的App，然后把它通过webpack改造成微前端的形式。 我们开始吧！ 这次所有配置都由我们来手动完成。 return ( <main>
a Demo for Micro-Frontend using Webpack5< ，filename是提供给其他服务加载的文件，exposes则是需要暴露的模块，remotes指定要使用的其它服务，shared则是配置公共模块（比如lodash这种） 提供了 exposes 选项的表示当前应用是一个 1.2K20发布于 2021-08-13 - 来自专栏Java架构师历程
微服务在微信的架构实践
作者｜许家滔 编辑｜田光 微服务的理念与腾讯一直倡导的“大系统小做”有很多相通之处，本文将分享微信后台架构的服务发现、通信机制、集群管理等基础能力与其上层服务划分原则、代码管理规则等。 过去几年，微信都是很敏捷地在开发一些业务。所以我们的底层架构需要支撑业务的快速发展，会有一些特殊的需求。 另外，目前整个微信团队已经有一千多人了，开发人员也有好几百。 三、高并发 基础架构 接下来看看我们的基础架构。 ? 整个微服务的架构上，我们通常分成这些部分： 服务布局 服务之间怎么做一些远程调用 容错（主要讲一下过载保护） 部署管理 服务布局 ? 早年我们 QQ 邮箱、微信、图像压缩、反垃圾都是一个 web 服务，只有存储层会独立到后面去，甚至用 web 直连 MySQL。因为它早期比较小，后来变大之后就用微服务架构。 2011 年起负责微信后台基础架构，包括分布式存储平台和后台服务框架等，覆盖微信账号 / 消息 / 朋友圈核心存储等，并为公众号 / 微信支付 / 微信企业号等等业务提供组件支持，近两年专注于后台服务质量提升和高性能架构
4.4K32发布于 2018-09-26 - 来自专栏前端博客
微前端学习笔记（1）：微前端总体架构概述，从微服务发微
，反观java 世界，学好 Spring MyBatis ,一路无忧，哎……微服务为了解决庞大的一整块后端服务带来的变更与扩展方面的限制，出现了微服务架构（Microservices）：微服务是面向服务架构 微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。 微前端微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。 微服务架构，可以解耦后端服务间依赖。而微前端，则关注于聚合前端应用。热闹驱动开发。新的技术，既然很热闹，那么就学吧。微前端的实现，意味着对前端应用的拆分。 这整个过程跟webpack5是没有绑定关系的，也就是说MF并非webpack5的专属功能，Rollup和webpack4都可以实现MF。
1.3K10编辑于 2024-06-06 Go 高频服务的 5 个「微优化」技巧
前置共识不谈“换框架”“重写架构”，只讲「今天就能改」的代码级技巧所有例子均基于net/http（标准库），不依赖Gin/Echo测试环境：Go1.24,AppleM5,gotest-bench=. 2.复用json.Encoder/*bytes.Buffer：用sync.Pool高频服务里，每秒创建几万个临时对象=GC压力山大❌每次新建Encoder展开代码语言：GoAI代码解释funchandler id=123）场景r.URL.Query().Get("name")getQueryParam(...)时间240ns42ns内存256B0B✅更强方案：用valyala/fasthttp（但侵入性强）5. http.ListenAndServe(":8080",mux)会：✅启用HTTP/2（ALPN+TLS协商开销）✅解析所有headers（哪怕你只用Content-Type）✅精简版Server（高频内网服务适用 buffer每次new字符串转换strconv.AppendXxx()fmt.Sprintf,time.FormatQuery参数手写keyscanner/fasthttpr.URL.Query()内网服务关
22210编辑于 2025-12-11- 来自专栏开发经验
架构的未来：微前端与微服务的融合
文章目录 微服务架构简介 微前端架构简介 微前端与微服务的融合 1. 共享服务 2. 基于事件的通信 3. 统一的身份和认证 4. 交付管道的集成 示例：使用微服务和微前端的电子商务平台 微服务架构 微前端架构 融合微服务和微前端 结论 欢迎来到架构设计专栏~架构的未来：微前端与微服务的融合 ☆* o(≧▽≦)o *☆嗨~我是 ❤️ 在当今快速发展的软件开发领域，架构设计一直是一个不断演化的领域。随着技术的不断发展，我们看到了微服务架构和微前端架构这两种新兴的架构风格的崭露头角。 微前端与微服务的融合 虽然微服务和微前端是两种不同的架构风格，但它们之间存在许多共通之处。它们都强调了模块化、独立开发和部署的概念。 同样，微前端架构可以将前端模块拆分为多个独立的部分，这些部分可以在不同的前端应用程序之间共享。通过将微服务和微前端中的共享部分抽象为可重用的服务，可以实现更好的代码复用。 2.
88510编辑于 2023-12-13 - 来自专栏高性能服务器开发
5 各类游戏对应的服务端架构
用户退出了，或者每隔5分钟检查到数据改动了，都会保存到磁盘。这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。 这样类型的服务器基本能稳定的为玩家提供游戏服务，一台网关服务1-2万人，后面的游戏服务器每台服务5k-1w，依游戏类型和复杂度不同而已，图中隐藏了很多不重要的服务器，如登录和管理。 如果一个 APRG游戏，每组服务器5千人都到不了的话，那么选择一套更为贴近实际情况的结构更为经济。 又由于动态负载均衡的引入，让无缝服务器如虎添翼，容纳着超过上一代游戏服务器数倍的人数上限，并提供了更好的游戏体验，我们称其为第三代游戏服务端架构。 类型5：战网游戏服务器 经典战网服务端和 RPG游戏有两个区别：RPG是分区分服的，北京区的用户和广州区的用户老死不相往来。
2.9K20发布于 2018-07-25 - 来自专栏肉眼品世界
8场5胜，微服务VS单体架构
越来越多的组织开始放弃单体应用，逐步转向微服务的架构模式–将业务流程分为多个独立的服务。 随着越来越多的实例在运行，单体应用比微服务需要更多的资源 资源使用率方面，微服务胜利了。 对比5：扩展的精确性 单体应用的扩展有多种办法，运行多个实例，或运行多个线程，或者使用非阻塞IO。 对于微服务架构，这三个也都是适用的。 但是，面对客户端越来越多的请求，由于微服务架构更精细，因此扩展单个服务也更加精细。所以，对于微服务来说，扩展既简单又精确。 在微服务架构体系中，数据需要在不同服务之间发送，从而会产生一定的开销。如果微服务还不是一个分布式架构，那么他的吞吐量还不如一个单体应用高。 单体应用获得了3场胜利，微服务获得了5场胜利。 但是，在查看此图表时，请记住它是相对的。微服务并不是解决所有开发问题的万能药。 例如，一个由5个开发人员组成的小型团队可能会倾向于选择单体应用。
1.4K20发布于 2020-11-17 - 来自专栏cloudskyme
一起玩转微服务（5）——分层架构
而微服务的每个架构都可以再细分成领域模型，下面看一下经典的领域模型架构。 它包括了Domain，Service Layer和Repositories。 - MicroService-Sample/src/ domain gateways interface repositories services 当然，在微服务的架构中 ，每个微服务不必严格遵照这样的规定，切忌死搬硬套，最重要的是理解，在不同的业务场合，架构的设计可以适当的做调整，毕竟适合的架构一定要具有灵活性。 分层的原则包括： 文件夹分层法 应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范，可以包括 5 个项目，也可以包括 50 个项目，以满足所有业务应用的多种不同场景。 调用规约 在开发过程中，需要遵循分层架构的约束，禁止跨层次的调用。 下层为上层服务 以用户为中心，以目标为导向。
1.1K21发布于 2020-06-22 - 来自专栏智能时刻
【微前端架构】AWS 上的微前端架构
微服务架构的特点是独立服务，这些服务专注于特定的业务功能，并由小型、自包含的团队维护。微服务架构经常用于在 AWS 上开发的 Web 应用程序，这是有充分理由的。 微前端架构将微服务开发原则引入前端应用程序。在微前端架构中，开发团队独立构建和部署“子”前端应用程序。这些应用程序由“父”前端应用程序组合而成，该前端应用程序充当容器来检索、显示和集成各种子应用程序。 带有微前端的微服务后端 微前端的好处 与单体前端相比，微前端具有以下优势： 独立工件：微服务开发的核心原则是工件可以独立部署，这对于微前端仍然适用。 在微前端架构中，团队应该能够独立部署他们的前端应用程序，而对其他服务的影响最小。这些更改将反映在父应用程序中。 自治团队：每个团队都是各自领域的专家。例如，计费服务团队成员具有专业知识。 结论 微前端架构为前端应用程序引入了微服务开发的许多熟悉的好处。微前端架构还允许您管理小型独立组件，从而简化构建复杂前端应用程序的过程。
2.5K10编辑于 2022-03-08 - 来自专栏数据猿
微信许家滔：微信10亿日活场景下，后台微服务架构及存储架构实践！
年5月上线了语音对讲、查看附近的人；2012年4年发布了里程碑式的朋友圈功能；2013年游戏中心、表情商店、微信支付等。 02 微信后台的系统架构 逻辑上讲，最前面会有一个终端，后面会有一个长链接接入层，在线有几亿的管理连接部分。 04 微信后台对高可用的定义 在高可用方面，我们先了解相关定义如下图所示： 最下面的2个9，是指一年故障时间不超过3.65天；最上面5个9 ，是指金融应用，一年故障时间不超过5分钟。 上面提到的这个论文是微信PaxosStore的一点创新，贡献出了一些简洁的算法实现流程，大家可以很轻松的去理解和实现。 06 PaxosStore整体架构 PaxosStore整体架构，如下图。 09 微信微服务架构框架 微服务包含了服务定义、服务发现、错误重试、监控容灾、灰度发布等一系列面向服务的高级特性的统一框架。
6.4K435发布于 2020-03-19 - 来自专栏智能时刻
【微服务架构】微服务架构——探索 UBER 的微服务架构
您可能会想到的下一个问题是使用微服务的应用程序如何处理它们的数据？ 5. 数据处理 好吧，每个微服务都拥有一个私有数据库来捕获它们的数据并实现各自的业务功能。 请注意本系列中的其他文章，这些文章将解释微服务的其他各个方面。 1. 什么是微服务？ 2. 微服务设计模式 3. 微服务与 SOA 4.微服务教程 5. 微服务设计模式 6. 【首席架构师圈】或者加微信小号【cea_csa_cto】或者加QQ群【792862318】公众号 【jiagoushipro】 【超级架构师】 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 微信小号 【cea_csa_cto】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化. 知识星球【职场和技术】微博【智能时刻】智能时刻哔哩哔哩【超级架构师】抖音【cea_cio】超级架构师快手【cea_cio_cto】超级架构师 小红书【cea_csa_cto】超级架构师 谢谢大家关注
92220编辑于 2022-03-24 - 来自专栏智能时刻
「微服务架构」企业微服务架构
首先，来自Darren的消息是，微服务架构并不是构建大规模企业应用程序的新方式。 Netflix和亚马逊等公司已经实施了微服务架构，在过去几年中提供了成功的产品。 但是微服务架构适合您的组织吗？ 监控部署生命周期的各个阶段 集中式架构团队与分散式架构团队 基建自动化 架构师的角色随着微服务的采用而发展，并委托他或她承担挑战性的责任，从而形成架构治理。 架构治理是组织尝试开始微服务之旅的关键因素之一，因为如果没有正确的顺序，该过程将很快导致微管理而不是微服务。 这意味着企业架构师不再需要承担单个服务的内部工作负担，而是高度关注整个系统中服务之间的交互。此外，架构师应密切关注系统的整体运行状况，以确保每项服务以一致的方式生成与监控相关的指标。 如果您正在寻找有关微服务架构的其他材料，请查看Martin Fowler的文章或ThoughtWorks网站上的其他微服务洞察博客。
1.1K22发布于 2018-12-24 - 来自专栏西岭老湿
微前端架构实战
可以理解微前端是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。 这种架构目前有多种方案，都有利弊之处，但只要适用当前业务场景的就是好方案。 微前端并没有技术栈的约束。每一套微前端方案的设计，都是基于实际需求出发。 微前端由于是多个子应用的聚合，如果多个业务应用依赖同一个服务应用的功能模块，只需要更新服务应用，其他业务应用就可以立马更新，从而缩短了更新流程和节约了更新成本。 使用微前端架构就可以解决问题，在保留原有项目的同时，可以完全使用新的框架开发新的需求，然后再使用微前端架构将旧的项目和新的项目进行整合。 模块联邦实现 Vue3.0 微前端架构 完整代码示例：modulefederationvue3: 基于模块联邦实现的 Vue3.0 微前端架构示例 (gitee.com) package.json {
4.7K00发布于 2021-04-25 - 来自专栏氧化先生的专栏
【架构拾集】 微前端：微应用化
微应用化即在开发和运行时，应用都是以单一、微小应用的形式存在。 微应用化与微前端架构相当的类似，它们在开发时都是独立应用，在构建时又可以按照需求单独加载。 关键因素 描述 对于 想拆解单体前端应用的团队 我们的架构 微应用化 是一个 类微前端架构 它可以 在开发环境将应用拆分成一个个的模块化应用，在构建时以单体的形式构建 但他不同于 微前端架构 它的优势是 微件化，即通过对构建系统的 hack，使不同的前端应用可以使用同一套依赖。它在应用微服务化的基本上，改进了重复加载依赖文件的问题。 架构设计方案 在刚结束的项目里，我们采用了这种架构方式来构建应用，我们将其称之为微应用。原因主要有两个，一个是每个应用都是以功能模块划分的，一个则是应用最后仍然是以单体应用的形式存在的。 使用 E2E 测试对于微前端或者微服务化架构来说，是一种特别有效的方式。唯一的问题可能是，它运行起来比较慢。
93130发布于 2018-08-21 - 来自专栏Java呓语
架构·微服务架构(一)
1、概述 微服务架构模式作为替代单体应用和面向服务架构的一个可行的选择，在业内迅速取得进展。由于这个架构模式仍然在不断的发展中，在业界存在很多困惑——这种模式关乎什么？它是如何实现的？ 微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。 2.3.1、单体应用的演变过程 单体应用：一个应用就是一个整体。 微服务架构通过简化服务概念、消除服务编排、简化服务组件连接和访问来解决复杂度问题。 3、模式实现 虽然有很多方法来实现微服务架构，这里提出三个脱颖而出的案例。 然而服务组件粒度过细，则很快会将微服务架构模式演变成一个复杂、容易混淆、代价昂贵并易于出错的重量级面向服务架构。 5、注意事项 微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。
1.9K20发布于 2018-08-21 - 来自专栏智能时刻
【韧性架构】让你的微服务容错的 5 种模式
现在，想象一下有这样的微服务链： 如果我们将每个服务的总尝试次数设置为 3 并且服务 D 突然开始服务 100% 的错误会发生什么？ 相反，重试请求超时或 5xx 是好的。 采用错误预算——技术，当可重试错误率超过阈值时停止重试，例如如果与服务 D 的 20% 的交互导致错误，请停止重试并尝试优雅降级。 首先，重新访问相互调用的相同服务链： 服务 A 愿意最多等待 400 毫秒并请求需要所有 3 个下游服务完成一些工作。假设服务 B 花了 400 毫秒，现在准备调用服务 C。这是否合理？不！ 所以，如果允许服务 A 等待 400ms，服务 B 花费 150ms，则在调用服务 C 时，它必须附加 250ms 的期限超时。 现在，响应时间增加了 50 毫秒（依赖服务开始做额外的工作）。从现在开始服务的每一秒都会面临越来越多的请求同时被处理，因为到达率大于服务率。
1.4K10编辑于 2022-06-08 - 来自专栏深度学习与python
了解新兴架构模式：微应用架构
本文讲述了微服务（Microservice）所启发的新兴架构模式如何为特性开发注入活力并加快开发者的速度。 20 世纪末，网络公司，如 Netflix 和亚马逊，都面临着大规模软件开发的挑战。 采用微应用架构。 1 什么是微应用？ 微服务将后端分离出来的区域单独部署。与此类似，移动开发者可以将应用程序的不同核心部分——单一特性、共享业务逻辑和低级特性——转移到独立的模块库中。 因此，微应用的架构包括一个模块化设计，并辅之以专门的应用程序（称为微应用），供开发和测试使用，这就是为了提高开发者的速度。 3 挑战与权衡 像任何架构模式一样，微应用的方法也有取有舍。微服务在很大程度上影响了微应用的架构，但这两者之间有一个关键的区别。微服务是单独部署的，而构成微应用的模块则是编译成相同的二进制文件。 4 微应用架构之路 采用微应用架构需要时间，需要大量的学习和实验。
92230发布于 2021-11-10 别再盲目微服务了！这 5 种场景适合单体架构
这 5 种场景适合单体架构 作者：全栈架构师 阅读时长：5 分钟 适合人群：技术负责人、架构师、3-5 年经验工程师 开篇：一个真实的案例 上周有个创业公司的 CTO 找到我，说他们遇到了大麻烦。 维度 5：成本控制 单体架构（以日活 1 万为例）： 服务器成本： - 应用服务器：2 台 × 2000 元/月 = 4000 元 - 数据库：1 台 × 3000 元/月 = 3000 元 - 缓存： ）： 服务器成本： - 应用服务器：10 台 × 2000 元/月 = 20000 元 - 数据库：3 台 × 3000 元/月 = 9000 元 - 中间件集群：5 台 × 2000 元/月 = 10000 元 - 监控日志：2 台 × 2000 元/月 = 4000 元 总计：43000 元/月（是单体的 5 倍） 人力成本： - 后端开发：6 人（每个服务至少 1 人） - 前端开发：3 人 - 测试 ✅ 场景 5：小型电商/内容平台 特征： •日活 < 5 万•QPS < 3000•团队 < 20 人 建议： 这个规模，单体架构 + 合理的缓存策略完全够用。
13410编辑于 2026-05-21- 来自专栏智能时刻
「微服务架构」Medium的微服务架构实践
我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。 在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。 什么是微服务架构？ 首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。 由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。 与此同时，了解微服务不是什么很重要： 微服务不是具有少量代码行或“微”任务的服务。 尽管微服务架构允许团队更轻松地测试新技术，但它并不是微服务架构的主要目标。只要团队从分离的服务中受益，就可以使用完全相同的技术堆栈构建新服务。 微服务不是必须从头开始构建的服务。 ¹在这篇文章中，我们将以两种方式使用“微服务”一词，（1）指微服务架构，（2）指微服务架构中的一项服务。 ²在开发中获取生产数据是一把双刃剑。
84621发布于 2019-06-28
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号