- 综合排序
- 最热优先
- 最新优先
- 来自专栏后端JavaEE
架构演进
一、架构演进 1.开发环境、测试环境/沙箱环境、生产环境（Linux操作系统） 2.单体架构 All in One 2.1web2.0用户激增，基于单体架构集群 2.2问题： 1.用户到底要访问那台服务器 效率更高，用户体验更好 3.垂直架构：江哥哥模块分开开发，并运行在自己的web容器中，相互独立 4.分布式架构：将各个模块分开开发，并运行在自己的web容器中，通过http/rpc的方式使模块之间相互通讯 ，像一些分布式框架，将三层拆开 4.1分布式架构面临的问题： 1.服务与服务之间如何实现异步通讯 2.通过Eureka获取服务地址信息，Ribbon实现负载均衡 3.Hysreix
37221发布于 2020-10-30 - 来自专栏東雲研究所
Serverless 架构演进
单体架构：最原始的站点架构模型，采用单一VPS或服务器做业务支撑。 SOA架构：最常用的企业架构，通过各个服务模块，将较为复杂的业务拆分治理。 容器架构：更好的SOA载体，底层计算的革新，但还是会强依赖自生运维能力。 Serverless架构：封装了所有底层资源管理和系统运维工作，使开发人员更容易使用云基础设施。
86800发布于 2020-02-07 - 来自专栏SRE运维实践
架构的演进
风言风语 1 架构的演进 在最早进行写程序的时候，都是单体应用程序，所谓的单体，就是一堆人写一个代码库，服务器也就是一个应用，一个数据库。 ? 在解决以上的两个问题的时候，就进化出了高可用架构，也就是使用负载均衡和集群的服务，应用变成多份，数据库也变成了高可用的架构。 ? 高可用架构的出现解决了单点问题，也解决了当容量性能不足的情况下，进行快速的扩容缩容的操作，但是随着业务的发展，人员组织架构的扩大，几十号人公用一个代码库，开发效率出现问题，各种上线的时候都需要大量的人力 ，从而出现了微服务架构。 微服务架构通过各种方法将单体架构的代码进行拆分为小的服务，从而每个小服务由专人来进行负责开发，升级，维护，从而大大的提高了研发效率，但是带来的问题也是很大的，有拆分的方法论，拆的好的提高研发效率，拆的不好的搞死开发
75620发布于 2020-12-11 - 来自专栏迈向架构师
凤凰架构 - 架构的演进
《凤凰架构：构建可靠的大型分布式系统》- 周志明 今天分享的凤凰架构是由周志明大佬开源撰写的架构书籍。 今天从架构的演进开始。 架构并不是被发明出来的，而是持续演进的结果。 原始分布式时代 最初的微型计算机只有不足 5MHz 时钟频率的处理器与 128KB 左右的内存地址空间。 ，具体业务以插件模块形式存在（但是各个插件不会直接交互） 事件驱动架构：在子系统之间建立一套事件队列管道，用来存储信息与分享信息 SOA架构（面向服务架构）：当系统演化至事件驱动架构时，原始分布式时代发展到此时 也列举了九个核心业务与技术特征： 围绕业务能力构建 分散治理 通过服务来实现独立自治的组件 产品化思维 数据去中心化 强终端弱管道 容错性设计 演进式设计 基础设施自动化 没有了统一的规范和约束，以前遇到的那些分布式问题在微服务中不再会有统一的解决方案 但它们两者并没有继承替代关系 无服务不是一定就会微服务更加先进，两者之间也并非相对，以后，无论是通过物理机、虚拟机、容器，抑或是无服务云函数，都会是微服务实现方案的候选项之一 如果你对这几个阶段的项目演进感兴趣
1.3K31编辑于 2023-02-25 - 来自专栏生如夏花的个人博客
软件架构的演进
软件架构的演进 软件架构的发展经历了从单体架构、垂直架构(分布式架构)、SOA架构到微服务架构的过程。 单体架构 Web应用程序发展的早期，大部分web工程师将所有的功能模块打包到一起并放在一个web容器中运行，所有功能 模块使用同一个数据库。 下图是一个单体架构的电商系统： ? 分布式架构 针对单体架构的不足，为了适应大型项目的开发需求，许多公司将一个单体系统按业务垂直拆分为若干系统，系统 之间通过网络交互来完成用户的业务处理，每个系统可分布式部署，这种架构称为分布式架构。 SOA架构 SOA是一种面向服务的架构，基于分布式架构，它将不同业务功能按服务进行拆分，并通过这些服务之间定义良好 的接口和协议联系起来。 ? 等，服务的粒度很小，所以称为微服务架构。
1.7K30发布于 2021-01-02 - 来自专栏黯羽轻扬
React Native 架构演进
写在前面 上一篇（React Native 架构一览）从设计、线程模型等方面介绍了 React Native 的现有架构，本篇将分析这种架构的局限性，以及 React Native 正在进行的架构升级计划 一.现有架构的局限性 最初的设计也带来了一些限制： 异步：无法将 JavaScript 逻辑直接与许多需要同步答案的 Native API 集成 批处理：很难让 React Native 应用调用 Native 二.架构升级计划 因此，2018 年 6 月提出大规模重构的计划，目的是更好地支持混合应用： We’re working on a large-scale rearchitecture of React 、Data Fetching 等等 Bridge：精简优化，允许 Native 与 JavaScript 之间的直接调用 支持同步调用让之前很难实现的一些东西成为了可能，例如跨语言的调用栈追踪 对应到架构图中 不同于之前直接将 JavaScript 代码输入给 JSC，新的架构中引入了一层 JSI（JavaScript Interface），作为 JSC 之上的抽象，用来屏蔽 JavaScript 引擎的差异
1.9K21发布于 2019-11-29 - 来自专栏架构兵法
什么是架构？架构如何演进？
我正在创作架构专栏，秉承ITer开源精神分享给志同道合（爱江山爱技术更爱美人）的朋友。专栏更新不求速度但求质量（曹大诗人传世作品必属精品，请脑补一下《短歌行》：对酒当歌，红颜几何？ ，通过朴实无华、通俗易懂的图文将十六载开发和架构实战经验娓娓道来，让读者茅塞顿开、相见恨晚...如有吹牛，不吝赐教。关注wx公众号：IT孟德，一起修炼吧！ 1、前言 我们的城市最初可能只是一个维持极少人生活的小渔村单体架构。 2、系统架构的定义 系统架构（System Architecture） 是描述单个或多个系统整体结构的设计蓝图，定义了系统的组件划分、部署策略、交互方式以及非功能性需求（性能、可用性、可扩展性 3、演进路径 架构演进通常遵循从简单到复杂、从集中到分布、从刚性到弹性的路径（实际可能会有交叉和重叠）。
30710编辑于 2025-06-24 - 来自专栏落影的专栏
工程架构持续演进
正文 整体视角 首先介绍工程当前整体设计，整体工程视角的架构图如下： 业务实现层和业务接口层，是常迭代的业务部分； 业务接口层，存放业务组件对外的能力，这些能力大部分用接口来表述。 架构演进 架构演进的思路，主要考虑当下要素： 1、多App迭代述求，以融合开发方式为多App提效，同时保留业务细节差异化能力，以及整体业务模块剥离的包体积优化空间； 2、SaaS同构迭代，未来相关业务既要接入 SaaS，又要迭代SaaS； 3、质量和效率提升，更加清晰的工程架构来承载复杂业务，层级之间更加清晰并有防劣化，复杂业务组件有良好设计来降低理解成本 基于上述分析和考虑，对原来架构进行进一步调整： 不依赖其他业务组件和服务层； 5、业务基础库和通用基础库分隔，业务基础库只服务于当前工程，通用基础库服务于类SaaS的多宿主； 6、配合多包SOP调整差异化组件，将大部分固定差异用配置化的方式进行处理； 总结 架构演进是一件需要持之以恒的事情 架构不是越复杂越好。越多的层级固然能更好做逻辑拆分、依赖隔离，但是也有更多的开发能力和理解能力要求。 如无必要，勿增实体。
29620编辑于 2023-07-31 - 来自专栏ThoughtWorks
演进式数据架构
本文借助于《演进式架构》这本书中关于演进式架构体系的描述，探索我们如何在数据这个领域，设计出演进式数据架构。 演进式架构支持跨多个维度的引导性增量变更。 ——《演进式架构》 这是《演进式架构》这本书第一章第一节对“演进式架构”的作用做出的简洁定义，也就是说演进式架构便是持续架构，因为在架构这件事上没有最终状态，它会随着软件开发体系的不断变化而演进，我们只能将时间和变化作为维度来定义 本文便是借助于《演进式架构》这本书中关于演进式架构体系的描述，探索我们如何在数据这个领域，设计出演进式数据架构。 这样的架构定义之间的跨度非常大，甚至不存在“演进”的可能性，几乎就是替换和重做，因此这种数据架构的定义太过于狭义，不太适用于我们去探讨数据架构如何演进。 ---- 架构解耦与演进 既然数据架构可以分为不同的类型，并且数据架构有着对应的适应度函数进行评估，那么我们可以基于此来探讨数据架构如何进行演进。
55010发布于 2021-02-08 - 来自专栏码匠的流水账
聊聊演进式架构
## 序 本文主要聊聊演进式架构 ## Evolutionary Architecture 它的定义原文如下： >An evolutionary architecture supports incremental 翻译过来大致是演进式架构是一种支持将增量式、指导式的变更作为跨多个维度中的第一原则的架构。 >定义fitness function的前提就是确定当前演进式架构中需要保持哪些capability，哪些capability可以被弱化或移除。 ! 因而Appropriate coupling就是演进式架构的核心，用来进行tradeoff，哪些可以以最小的代价提供最好的收益而允许适度耦合。 架构则是拥抱未知的变化，在不同的变化中不断取舍，进行演进。
86710发布于 2018-09-17 - 来自专栏Java职业技术分享
Python后端架构演进
来腾讯之前在前公司做了3年的后端开发，经历一款SaaS产品从0到10（还没有到100, 哈哈哈）的过程，3年间后端的架构逐步演变，在微服务的实践过程中遇到的问题也越来越多，在这里总结下。 架构的演进经历了4个大的阶段：1. MVC 2. 服务拆分 3. 微服务架构 4. 领域驱动设计 1. 整体上架构如上图，Nginx负责负载均衡，分发流量到多个Django服务，Django处理逻辑，需要异步任务就交给Celery，然后数据量比较大的地方使用Redis做缓存。 在我离职时领域驱动设计还在学习设计阶段，还没有落地，但是我相信前公司的后端架构一定会往这个方向继续演进。 总结 架构的设计，技术的选型，不能完全按照流行的技术走，最终还是服务于产品，服务于客户的需求。 Service Mesh这种新一代的微服务架构正在成为主流，虽然现在的工作与微服务无关了，但是也还会继续关注学习。
7K30发布于 2018-09-29 - 来自专栏迁移内容
JavaWeb：JavaWeb技术架构演进
～ 本篇内容包括：JavaWeb 简介、JavaWeb 技术架构演进的各个阶段，即 JavaWeb-Servlet 阶段，JavaWeb-MVC 阶段（SSM/SSH）以及 JavaWeb-SpringBoot 、JavaWeb-MVC 阶段 1、MVC 模式概述 MVC（Model–view–controller）模式，最早由 Trygve Reenskaug 在 1978 年提出，它是软件工程中的一种软件架构模式 Struts 作为系统的整体基础架构，负责 MVC 的分离，在 Struts 框架的模型部分，控制业务跳转； Hibernate 框架对持久层提供支持； Spring 做管理，管理 struts 和 hibernate 绝对没有代码生成以及不要求配置 XML Ps：SpringBoot 虽然目的是为了简化 Spring，似乎看起来无需去学习 Spring 的繁琐配置，但是如果没有忍受过Spring的繁琐配置，没有经历过架构模式的演进以及
2.2K20编辑于 2022-12-02 - 来自专栏得物技术
Serverless架构演进与实践
2.架构演进图片早期的软件部署模式是通过采购物理机的形式，有多大规模采购多少台机器，采购多了或者配置差了都会存在比较大的资源浪费。 这个时候云厂商开始考虑是否可以把运维这个事情从开发手中收走，让运维自动化，变得对开发更加透明，开发人员只需关注核心业务逻辑的开发，进而精益整个产品开发流程，快速适应市场变化，这个时候Serverless的概念开始产生，所以从这个角度来看，在整个it架构演进中 从整个演进过程中来看，一直都在朝着资源切分粒度越来越细(物理机->操作系统->进程->function)，资源利用率越来越高，运维工作逐渐减少，开发更聚焦业务的方向发展的，Serverless的产生也是符合历史发展的一般规律 Serverless如何影响微服务微服务和Serverless并不冲突，一个微服务应用可以是基于Serverless架构搭建部署的，也可以是传统的先申请资源再进行部署的方式，Serverless本身是技术架构 ，而微服务是业务架构，经济基础决定上层建筑，底层的技术架构形式会影响上层的业务，当Serverless以function为粒度提供服务的时候，对于上层微服务的架构组织带来了新的契机。
1.8K72编辑于 2022-10-13 - 来自专栏我思故我在
DevOps平台架构演进
本文将介绍明源云研发协同平台的架构从0到1，逐步随着业务发展一步一步迭代演进的过程。 ，而演进的主要方式则是服务化、集群化 架构演进的五条原则 既然要对架构进行升级重构，那么有没有一些基本的准则，指导我们避免一些坑呢？ 基于此，我们尝试总结了架构演进的五条原则： 确定当前的架构现状：每次架构演进，一定是针对当前架构的，所以必须非常清楚当前的架构现状和问题。清楚现状，明白目标，才能逐步改进，向目标前进。 在重构前，我们需要回答架构演进原则提出的问题： 确定当前的架构现状：所有服务集中在一起运行。 ，治理，提供服务和资源的运维、监控能力，而都需要架构 向微服务架构演进 在进行微服务架构重构之前，我们同样需要回答架构演进原则提出的问题： 确定重构的目的和必要性 - 随着产品的持续迭代，业务复杂度越来越大
2K53发布于 2019-07-15 - 来自专栏服务端技术杂谈
通用业务系统架构演进
随着业务的越来越繁杂，系统会变得越来越复杂，除了需要在技术角度去满足系统的高性能，稳定性，高可用等需求外，设计可以满足业务需求迭代的架构同样重要。 通用业务系统实现 系统初期往往采用三层架构方式搭建，上层为controller，中间层为service，下层的数据访问为dao层。 业务组件的形成往往是在对业务理解深刻之后演进出来的，过早的抽象往往效果不好。 组件内聚之后可能产生如：短信组件，下单组件扽。 多种组件可以组合产生业务流程的能力。
1.3K30发布于 2019-03-14 - 来自专栏麒思妙想
读《演进式架构》有感
最近读了一本很有意思的书《演进式架构》，从一个不太一样的角度来描述架构这件事。也让我痛定思痛的反省了一下过去犯的错误，以及由于知识欠缺，所留下的遗憾。 翻译过来大致是演进式架构是一种支持将增量式、指导式的变更作为跨多个维度中的第一原则的架构。 如果系统架构不支持，你无法建立一个高效的组织。 当然有些架构是用来抛弃/牺牲的。比如可牺牲的架构中提到的： 支持1996年eBay的合适架构，对于2006年eBay来说，就不是合适的了。 1996年的架构无法处理2006年的负载，但是2006年的版本太过复杂而难以建立、维护，它是根据1996年的需求演化而来的。的确，这个原则可以引出工作的一种组织方式。
64230发布于 2020-07-10 - 来自专栏DDD
架构如何迭代演进
最近看完了一本大佬很早就推荐的书：《演进式架构》 现在看已经算是一本很老的书了，里面的很多概念对架构师来讲已经算是耳熟能详了。 如何应对，演进式架构应运而生：演进式架构支持跨多个维度的引导性增量变量，主要由三方面构成：增量变更、适应度函数、适当的耦合。 构建演进式架构的关键之一在于决定自然组件的粒度以及它们之间的耦合，以此来适应那些通过软件架构支持的能力。 架构师一直在与耦合斗争，架构一直在演进，最原始的大泥球架构进化到单体分层架构再到微服务架构。 原因二：能明确演进式架构的长远价值。原因三：用最有价值的部分来审查此架构方法，能够为是否继续提供可行的数据。 构建可演进的架构会耗费额外的时间和精力，但好处是公司可以应对市场的重大变化，而不需要大量返工。 总结 简而言之，《演进式架构》提供了一种架构迭代的指导方法，就如同重构代码一样。
1.2K10编辑于 2022-03-11 - 来自专栏微信公众号【Java技术江湖】
淘宝技术架构演进之路
1、概述 本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 3、架构演进 3.1、单机架构 ? 以淘宝作为例子。在网站最初时，应用数量与用户数都较少，可以把Tomcat和数据库部署在同一台服务器上。 随着用户数的增长，并发读写数据库成为瓶颈 3.3、第二次演进：引入本地缓存和分布式缓存 ? 随着用户数的增长，单机的写库会逐渐会达到性能瓶颈 3.7、第六次演进：把大表拆分为小表 ? 而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。 4.4、有没有一些架构设计的原则？
4.1K33发布于 2019-09-24 - 来自专栏Spark学习技巧
小米OLAP服务架构演进
可以看到，在旧版的架构中，Kudu表相关的权限和元数据与Hive表相关的权限和元数据，无论在实现上还是底层存储上都是分离的。 了解完旧版本的架构，就可以更彻底地了解这样的架构带来了的问题： 1、用户角度： （1）用户使用 OLAP 服务时，如果要访问 Kudu 表，需要对 SparkSQL队列进行特殊配置，以开启对 Kudu （2）虽然早期架构在代码层对meta 做了合并，但是并未从根本上解决权限分离的情况。 对于开发者，这种架构整体上更为清晰，在修改和维护上也更方便。 OLAP 2.0架构图 >>>> 展望 基于整合后的架构，未来我们可以提供更多的能力，比如基于HMS的元数据服务，基于Sentry的权限服务。
1.2K20发布于 2019-11-07 - 来自专栏java架构计划训练营
大型网站架构演进历程
以上演进历程是绝大多数公司的一个演进历程，但是这个不是标准的，不是说必须要在某一个阶段的时候才能使用其中的一些知识点。 Web 1.0 时代 没有交互，只展示内容 Web 2.0 时代 有了一定的交互 最初的单体架构 访问量不大，所有应用用到的相关资源都在一台服务器上 最初的分离架构 将不同的资源，如文件存储服务 、数据库服务分开部署，让这些应用能获得更多的机器资源 缓存架构 当用户增多，查询变多变延迟的时候，加入缓存，拦截掉大部分的查询请求，降低数据库的负载 集群架构 单体架构存在瓶颈，用户继续增多时，就需要使用集群来承担更多的访问请求 数据库读写分离架构 业务不断的增长，用户也不断的增长，数据库，数据库负载又称为了瓶颈，使用读写分离架构 分库分表架构 业务继续发展，当数据量很庞大的时候，单库无法容纳下了，则使用分库分表，这是对数据库的最后一步 形成了微服务架构
78020编辑于 2022-06-14
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号