应用架构

服务端高并发分布式架构演进之路

蹲街弑〆低调 提交于 2020-02-27 02:28:17
1. 概述 本文以淘宝作为例子,介绍从一百个到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则。 特别说明:本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题,并非是淘宝真正的技术演进路径 2. 基本概念 在介绍架构之前,为了避免部分读者对架构设计中的一些概念不了解,下面对几个最基础的概念进行介绍: 分布式 系统中的多个模块在不同服务器上部署,即可称为分布式系统,如Tomcat和数据库分别部署在不同的服务器上,或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时,其他节点能够接替它继续提供服务,则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务,这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上,共同组成一个整体提供集中配置服务。在常见的集群中,客户端往往能够连接任意一个节点获得服务,并且当集群中一个节点掉线时,其他节点往往能够自动的接替它继续提供服务,这时候说明集群具有高可用性 负载均衡 请求发送到系统时,通过某些方式把请求均匀分发到多个节点上,使系统中每个节点能够均匀的处理请求负载,则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时

轻松构建基于 Serverless 架构的小程序

旧城冷巷雨未停 提交于 2020-02-26 07:49:07
前言 自 2017 年第一批小程序上线以来,越来越多的移动端应用以小程序的形式呈现。小程序拥有触手可及、用完即走的优点,这大大降低了用户的使用负担,使小程序得到了广泛的传播。在阿里巴巴,小程序也被广泛地应用在淘宝/支付宝/钉钉/高德等平台上。 为了支撑大量的小程序,服务端面临的挑战有: 大量的小程序是不活跃的,传统的至少一台服务器的方式会造成资源浪费; 在活动高峰期小程序的调用量激增,要求服务端能够快速进行弹性伸缩。 而小程序开发者往往是客户端/前端的开发者,更多的精力在开发业务代码与应用的快速上线上,而无心顾暇服务端的运维操作。 阿里云 函数计算 是一个全托管 Serverless 计算服务,让开发者无需管理服务器等基础设施,只需编写和上传代码,就能够构建可靠、弹性、安全的服务。 函数计算弹性、免运维、高效、安全的特性十分适合作为小程序的服务端。 解决方案 函数计算封装了一套小程序服务端模板,帮助小程序开发者快速搭建基于函数计算的小程序。 使用这个模板搭建小程序应用具有以下特点: 运维效率高: 无需管理服务器,部署函数即可上线 开发效率高: 基于封装好的数据接口,直接开发业务代码 零费用启动: 服务端基于函数计算,数据库采用表格存储,都是按量付费并且有较大的免费额度 小程序的工作流程 一个完整的支付宝小程序需要以下几个元素: 支付宝 App:是支付宝小程序的载体,运行在用户手机端

轻松构建基于 Serverless 架构的小程序

孤者浪人 提交于 2020-02-26 02:34:19
前言 自 2017 年第一批小程序上线以来,越来越多的移动端应用以小程序的形式呈现。小程序拥有触手可及、用完即走的优点,这大大降低了用户的使用负担,使小程序得到了广泛的传播。在阿里巴巴,小程序也被广泛地应用在淘宝/支付宝/钉钉/高德等平台上。 为了支撑大量的小程序,服务端面临的挑战有: 大量的小程序是不活跃的,传统的至少一台服务器的方式会造成资源浪费; 在活动高峰期小程序的调用量激增,要求服务端能够快速进行弹性伸缩。 而小程序开发者往往是客户端/前端的开发者,更多的精力在开发业务代码与应用的快速上线上,而无心顾暇服务端的运维操作。 阿里云 函数计算 是一个全托管 Serverless 计算服务,让开发者无需管理服务器等基础设施,只需编写和上传代码,就能够构建可靠、弹性、安全的服务。 函数计算弹性、免运维、高效、安全的特性十分适合作为小程序的服务端。 解决方案 函数计算封装了一套小程序服务端模板,帮助小程序开发者快速搭建基于函数计算的小程序。 使用这个模板搭建小程序应用具有以下特点: 运维效率高: 无需管理服务器,部署函数即可上线 开发效率高: 基于封装好的数据接口,直接开发业务代码 零费用启动: 服务端基于函数计算,数据库采用表格存储,都是按量付费并且有较大的免费额度 小程序的工作流程 一个完整的支付宝小程序需要以下几个元素: 支付宝 App:是支付宝小程序的载体,运行在用户手机端

TMS320F28051单片机解密型号

自闭症网瘾萝莉.ら 提交于 2020-02-25 19:17:17
TI 领先的 DSP 技术的处理能力和效率实现了 MCU 的控制外设集成和简便易用性,是诸如数字电机控制、数字电源和智能传感器等嵌入式应用的理想选择。致芯对于DSP系列芯片解密有明显优势。 TMS320F28051基本特性: 高效 32 位 CPU (TMS320C28x) 60MHz(16.67ns 周期时间) 16 × 16 和 32 × 32 乘法和累加 (MAC) 运算 16 × 16 双 MAC 哈佛 (Harvard) 总线架构 连动运算 快速中断响应和处理 统一存储器编程模型 高效代码(使用 C/C++ 和汇编语言) 部分芯片型号如下: TMS320LF2406A TMS320F28027 TMS320F2809 TMS320F28335 TMS320F2810 TMS320F28022 TMS320F2802 TMS320F2811 TMS320F28026 TMS320F2808 TMS320F28334 TMS320LF2407A TMS320F28021 TMS320F2806 TMS320F28332 TMS320LF2402A TMS320F2812 TMS320F28235 TMS320F2802 TMS320F2811 TMS320F28062 TMS320F28050 TMS320F28068 TMS320F28054 来源: 51CTO 作者:

[译]软件架构师之路

拟墨画扇 提交于 2020-02-25 19:12:37
今天给大家带来一篇自己翻译的干货《软件架构师之路》。本周Github上升很快的项目。其内容对致力于成为软件架构师(不论前后端)的同学应该都会有极大的帮助。 项目地址: 中文地址 https://github.com/gamedilong/SoftwareArchitect-CN 原文地址 https://github.com/justinamiller/SoftwareArchitect 如果有看完英文原文,发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR,如能够对大家起到一定的帮助也欢迎star 内容 什么是软件架构 软件架构的层次 软件架构师的典型工作内容 软件架构师的重要技能 架构师的技术路线图 相关书籍 什么是软件架构? 软件架构师是一名软件开发专家,他可以进行高层设计选择并决定技术标准,包括软件编码标准,工具和平台。 (出处: 维基百科:软件架构师) 软件架构(architecture)是一个系统的基本组织,由其组件、它们之间的相互关系和环境以及决定系统设计和演化的原则来表示。 (出处: 软件架构手册) 软件架构的层次 软件架构可以被抽象的分为几个层次,不同的层次对技能的要求不同。对层次有很多不同的划分,我最喜欢如下这三种划分: 应用级 : 最低层次的架构。聚焦单个具体的应用。 非常注重细节, 底层设计。 沟通仅限入单个开发团队。 解决方案级 : 中级别的架构

SDN概述及架构

纵然是瞬间 提交于 2020-02-21 22:28:41
原文链接:https://blog.csdn.net/weixin_43265596/article/details/89787232 一、SDN概述 1.1 SDN概念 SDN是一种将网络控制功能与转发功能分离、实现控制可编程的新兴网络架构。这种架构将从控制层从网络设备转移到外部计算设备,使得底层的基础设施对于应用和网络服务而言是透明的、抽象的,网络可被视为一个逻辑的或虚拟的实体。 1.2 SDN产生的原因 传统网络及其设备的只可配置、不可编程 网络的分布式控制与管理架构带来的制约 二、SDN架构 2.1 SDN的基本架构 SDN采用了集中式的控制平面和分布式的转发平面,两个平面相互分离,控制平面利用控制—转发通信接口对转发平面上的网络设备进行集中式控制,并提供灵活的可编程能力,具备以上特点的网络架构都可以被认为是一种广义的SDN。 在 SDN 架构中,控制平面通过控制—转发通信接口对网络设备进行集中控制,这部分控制信令的流量发生在控制器与网络设备之间,独立于终端间通信产生的数据流量,网络设备通过接收控制信令生成转发表,并据此决定数据流量的处理,不再需要使用复杂的分布式网络协议来进行数据转发,如下图所示。 SDN 并不是某一种具体的网络协议,而是一种网络体系框架,这种框架中可以包含多种接口协议。如使用OpenFlow等南向接口协议实现SDN 控制器与 SDN 交换机的交互

云架构师进阶攻略

独自空忆成欢 提交于 2020-02-16 07:56:15
https://mp.weixin.qq.com/s/tHRl5OQHY2mNXqKwACCVWw?utm_source=tuicool&utm_medium=referral 一、架构的三个维度和六个层面 1.1、三大架构 在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构。 第一个是IT架构,其实就是计算,网络,存储。这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担。数据中心,虚拟化,云平台,容器平台都属于IT架构的范畴。 第二个是应用架构,随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的弹性还不够,常常会出现创建了大批机器,仍然撑不住高并发流量。因而基于微服务的互联网架构,越来越成为云架构师所必需的技能。良好设计的应用架构,可以实现快速迭代和高并发。数据库,缓存,消息队列等PaaS,以及基于SpringCloud和Dubbo的微服务框架,都属于应用架构的范畴。 第三个是数据架构,数据成为人工智能时代的核心资产,在做互联网化转型的同时,往往进行的也是数字化转型,并有战略的进行数据收集,这就需要云架构师同时又大数据思维。有意识的建设统一的数据平台,并给予数据进行数字化运营。搜索引擎,Hadoop,Spark,人工智能都属于数据架构的范畴。 1.2、六个层面 上面的三个维度是从人的角度出发的

YARN的架构及原理

梦想的初衷 提交于 2020-02-15 11:14:45
1.YARN产生背景 1.1 MapReduce本身存在的问题 JobTracker单点故障问题;如果Hadoop集群的JobTracker挂掉,则整个分布式集群都不能使用了。 JobTracker承受的访问压力大,影响系统的扩展性。 不支持MapReduce之外的计算框架,比如Storm、Spark、Flink等。 1.2 MRv1 JobTracker:用户程序提交了一个Job,任务(job)会发给JobTracker,JobTracker是Map-Reduce框架中心,它负责把任务分解成map和reduce的作业(task);需要与集群中的机器定时心跳(heartbeat)通信;需要管理那些程序应该跑在那些机器上;需要管理所有job失败、重启操作。 Tasktracker是JobTracker和Task之间的桥梁,Tasktracker可以配置map和reduce的作业操(task slot)。TaskTracker通过心跳告知JobTracker自己还有空闲的作业Slot时,JobTrackr会向其分派任务。它将接收并执行JobTracker的各种命令:启动任务、提交任务、杀死任务。 TaskScheduler工作再JobTracker上。根据JobTracker获得的slot信息完成具体的分配工作,TaskScheduler支持多种策略以提高集群工作效率。 局限性

数字化转型之基础设施篇 | QingStor®️NeonSAN®️ 企业云存储实践

萝らか妹 提交于 2020-02-12 02:34:22
据 IDC 最新报告预测,2022 年中国 50% 以上的组织都将成为数字化坚定者,依靠新的商业模式、数字化产品与服务实现业务增长。 面对数字化转型的时代浪潮,青小云为大家准备了一份硬核大礼 —— 《数字化转型之路》 ,包含 基础设施 、 业务架构 、 解决方案 到 行业实践 、 未来探索 五个部分,该系列 是对数字化转型理论与具体实践路径的系统梳理 ,希望帮助读者全面准确把握数字化转型发展趋势与前沿技术,促进企业与组织能够在变革的数字化世界中创造更大的价值,实现更强健的生命力。 今天与大家分享的是《数字化转型之路》中基础设施篇——利用 QingStor®️NeonSAN®️ 打造强劲的核心业务存储引擎。 以下是分享正文: Neon 是一个惰性气体,它是化学元素周期表第十位,不燃烧、不助燃,不活跃, 非常稳定。我们通过这个名字命名我们的存储,希望存储产品像惰性气体一样地稳定,因为稳定是存储最根本的要求。 为企业核心业务而生的 QingStor®️ NeonSAN®️ NeonSAN®️ 作为企业级软件定义的分布式块存储,它在青云经历了多年的研发迭代与广泛的用户验证。分布式存储是 QingCloud 云平台体系中的重要组成部分,很早就以云平台超融合的方式为客户提供服务。后面我们发现很多客户提出独立存储需求,我们把云平台的存储进行解耦,作为独立产品推出。 NeonSAN®️

Saas 应用12个架构规范

故事扮演 提交于 2020-02-10 20:31:12
引言 如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或软件即服务(SaaS)。12-Factor 为构建如下的 SaaS 应用提供了方法论: 使用 标准化 流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目。 和操作系统之间尽可能的 划清界限 ,在各个系统中提供 最大的可移植性 。 适合 部署 在现代的 云计算平台 ,从而在服务器和系统管理方面节省资源。 将开发环境和生产环境的 差异降至最低 ,并使用 持续交付 实施敏捷开发。 可以在工具、架构和开发流程不发生明显变化的前提下实现 扩展 。 这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。 特别声明 本文转自国外一篇文章,由Adam Wiggins所著,原文地址: https://12factor.net/ 在此文基础上增加个人的理解以及部分图解。 统一源代码管理系统 一份基准代码(Codebase),多份部署(depl o y) 在类似 SVN 这样的集中式版本控制系统中, 基准代码 就是指控制系统中的这一份代码库;而在 Git 那样的分布式版本控制系统中, 基准代码 则是指最上游的那份代码库。 基准代码和应用之间总是保持一一对应的关系: 一旦有多个基准代码,就不能称为一个应用,而是一个分布式系统。分布式系统中的每一个组件都是一个应用,每一个应用可以分别使用 12-Factor