• 自动秒收录
  • 软件:1973
  • 资讯:56215|
  • 收录网站:181187|

IT精英团

真正的建筑设计是什么样子的?

真正的建筑设计是什么样子的?

浏览次数:
评论次数:
编辑: 温瑜
信息来源: ITPUB
更新日期: 2022-05-20 21:38:44
摘要

什么是架构和架构本质在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的

  • 正文开始
  • 相关阅读
  • 推荐作品

什么是架构和架构本质

在软件行业,关于什么是架构有很多争论,每个人都有自己的理解。这个君主说的建筑和他理解的建筑不一定是一样的。所以,在讨论建筑之前,我们先来讨论一下建筑的概念定义。概念是人们认识世界的基础,是交流的手段。如果对架构概念的理解不同,交流自然不会顺畅。

Linux有架构,MySQL有架构,JVM有架构,使用Java开发,MySQL存储,运行在Linux上的业务系统也有架构。应该注意哪一个?要理解以上问题,需要梳理几个相关且相近的概念:系统与子系统、模块与构建、框架与架构3360。

1.1. 系统与子系统

系统:一般指一组相关的个体,按照一定的规则运行,能够完成单个部件独立完成不了的工作能力。

子系统:它也是一个由一组相关个体组成的系统,大多是一个更大系统的一部分。

1.2. 模块与组件

都是系统的一部分,只是从不同的角度拆分了系统。模块是逻辑单元,组件是物理单元。

模块就是对系统进行逻辑分解,也就是分而治之,把复杂的问题简单化。模块的粒度可大可小,可以是系统、几个子系统、某个服务、函数、类、方法、功能块等。

组件可以包括应用服务、数据库、网络、物理机器、MQ、容器、Nginx和其他技术组件。

1.3. 框架与架构

它是组件实现的规范,如MVC、MVP、MVVM等。是提供基本功能的产品,比如开源框架:Ruby on Rails、Spring、Laravel、Django等。可以直接使用,也可以在此基础上进行二次开发。

框架是规范,架构是结构。

我在这里重新定义架构:软件架构是指软件系统的顶层结构。

架构是经过系统思考,权衡利弊,在现有资源约束下最合理的决定。最后,一个清晰的系统骨架:包括子系统、模块和组件,以及它们之间的协作关系、约束规范和指导原则。它引导团队中的每个人在思想层面上达成一致。涉及四个方面:

系统思考的合理决策:如技术选择、解决方案等。

明确系统骨架:明确系统由哪些部分组成。

系统协作:所有组件如何协作来实现业务请求。

规范和指导原则:确保系统有序、高效、稳定运行。

所以建筑师有能力:理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施.

架构的本质是对系统进行有序的重构,以符合当前的业务发展并快速扩展。

应该考虑什么样的制度?架构设计技术不会无缘无故的发展和自我驱动,但架构的发展和需求是由业务驱动的。

该架构完全是为业务而设计的,

需求相对复杂。

非功能性需求在整个系统中占据重要地位。

系统生命周期长,需要可扩展性。

基于系统组件或集成的需要。

业务流程再造的需要。

架构分层和分类

架构可以细分为业务架构、应用架构、技术架构、代码架构和部署架构。

业务架构是战略,应用架构是战书,技术架构是装备。其中,应用架构承上启下。一方面承担业务架构的落地,另一方面影响技术选择。

熟悉业务,形成业务架构,根据业务架构做出相应的应用架构,最后实现技术架构。

如何根据当前需求选择合适的应用架构,如何面向未来,保证架构的平稳过渡,是软件开发人员尤其是架构师需要深入思考的问题。

2.1. 业务架构(俯视架构):

包括业务规划、业务模块、业务流程、整个系统的业务拆分、领域模型的设计以及

没有最优的架构,只有最适合的架构。所有的系统设计原则都应该以解决业务问题为目标。脱离实际业务的技术情怀架构往往会把系统带进一个大坑。任何不是基于商业的异想天开的架构都是流氓。

所有问题的前提都是搞清楚我们今天面临的业务量有多大,增长趋势是什么,解决高并发的过程一定是一个循序渐进的过程。合理的结构可以提前预见业务发展。

1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

看看京东业务架构(网上分享图):

图片

2.2. 应用架构(剖面架构,也叫逻辑架构图)

硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

类似:

图片

应用架构:应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

应用架构图关键有2点:

①. 职责划分: 明确应用(各个逻辑模块或者子系统)边界

  • 逻辑分层
  • 子系统、模块定义。
  • 关键类。

②. 职责之间的协作:

  • 接口协议:应用对外输出的接口。
  • 协作关系:应用之间的调用关系。

应用分层有两种方式:

  • 一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。
  • 另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

2.3. 数据架构

数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

图片

2.4. 代码架构(也叫开发架构)

子系统代码架构主要为开发人员提供切实可行的指导,如果代码架构设计不足,就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件,结果公司整体架构设计就会失控。

代码架构主要定义:

①. 代码单元:

  • 配置设计
  • 框架、类库。

②. 代码单元组织:

  • 编码规范,编码的惯例。
  • 项目模块划分
  • 顶层文件结构设计,比如mvc设计。
  • 依赖关系
图片

2.5. 技术架构

技术架构:确定组成应用系统的实际运行组件(lvs,nginx,tomcat,php-fpm等),这些运行组件之间的关系,以及部署到硬件的策略。

技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

2.6. 部署拓扑架构图(实际物理架构图)

拓扑架构,包括架构部署了几个节点,节点之间的关系,服务器的高可用,网路接口和协议等,决定了应用如何运行,运行的性能,可维护性,可扩展性,是所有架构的基础。这个图主要是运维工程师主要关注的对象。

图片

物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

图片

架构级别

我们使用金字塔的架构级别来说明,上层级别包含下层:

  • 系统级:即整个系统内各部分的关系以及如何治理:分层
  • 应用级:即单个应用的整体架构,及其与系统内单个应用的关系等。
  • 模块级:即应用内部的模块架构,如代码的模块化、数据和状态的管理等。
  • 代码级:即从代码级别保障架构实施。

战略设计与战shu设计

基于架构金字塔,我们有了系统架构的战略设计与战shu设计的完美结合:

  • 战略设计:业务架构用于指导架构师如何进行系统架构设计。
  • 战shu设计:应用架构要根据业务架构来设计。
  • 战shu实施:应用架构确定以后,就是技术选型。
图片

应用架构演进

业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地。

图片

架构演进路程:单体应用→分布式应用服务化→微服务

4.1. 单体应用

企业一开始业务比较简单,只应用某个简单场景,应用服务支持数据增删改查和简单的逻辑即可,单体应用可以满足要求。

典型的三级架构,前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示:

图片

针对单体应用,非功能性需求的做法:

  • 性能需求:使用缓存改善性能
  • 并发需求:使用集群改善并发
  • 读写分离:数据库地读写分离
  • 使用反向代理和cdn加速
  • 使用分布式文件和分布式数据库

单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面是单体架构应用的一些缺点:

  • 复杂性高:以一个百万行级别的单体应用为例,整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战, 甚至添加一个简单的功能, 或者修改一个Bug都会带来隐含的缺陷。
  • 技术债务:随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并且越积 越多。“ 不坏不修”, 这在软件开发中非常常见, 在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改,因为应用程序中的其他模块可能会以意料之外的方式使用它。
  • 部署频率低:随着代码的增多,构建和部署的时间也会增加。而在单体应用中, 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高, 这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高。
  • 可靠性差:某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃。
  • 扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU;有的模块则是IO密集型的,需要更大的内存。由于这些模块部署在一起,不得不在硬件的选择上做出妥协。
  • 阻碍技术创新:单体应用往往使用统一的技术平台或方案解决所有的问题, 团队中的每个成员 都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。

4.2. 分布式

随着业务深入,业务要求的产品功能越来越多,每个业务模块逻辑也都变得更加复杂,业务的深度和广度都增加,使得单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,增加新功能开发周期越来越长,维护成本越来越高。

这时需要对系统按照业务功能模块拆分,将各个模块服务化,变成一个分布式系统。业务模块分别部署在不同的服务器上,各个业务模块之间通过接口进行数据交互。

该架构相对于单体架构来说,这种架构提供了负载均衡的能力,大大提高了系统负载能力,解决了网站高并发的需求。另外还有以下特点:

  • 降低了耦合度:把模块拆分,使用接口通信,降低模块之间的耦合度。
  • 责任清晰:把项目拆分成若干个子项目,不同的团队负责不同的子项目。
  • 扩展方便:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
  • 部署方便:可以灵活的进行分布式部署。
  • 提高代码的复用性:比如Service层,如果不采用分布式rest服务方式架构就会在手机Wap商城,微信商城,PC,Android,iOS每个端都要写一个Service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。
  • 缺点:系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。

4.3. 微服务

紧接着业务模式越来越复杂,订单、商品、库存、价格等各个模块都很深入,比如价格区分会员等级,访问渠道(app还是PC),销售方式(团购还是普通)等,还有大量的价格促销,这些规则很复杂,容易相互冲突,需要把分散到各个业务的价格逻辑进行统一管理,以基础价格服务的方式透明地提供给上层应用,变成一个微内核的服务化架构,即微服务。

微服务的特点:

  • 易于开发和维护:一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。
  • 单个微服务启动较快:单个微服务代码量较少, 所以启动会比较快。
  • 局部修改容易部署:单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
  • 技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库MySQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用Node.js开发。

微服务虽然有很多吸引人的地方,但它并不是免费的午餐,使用它是有代价的。使用微服务架构面临的挑战。

  • 运维要求较高:更多的服务意味着更多的运维投入。在单体架构中,只需要保证一个应用的正常运行。而在微服务中,需要保证几十甚至几百个服务服务的正常运行与协作,这给运维带来了很大的挑战。
  • 分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
  • 接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。
  • 重复劳动:很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件,需要该功能的微服务引用该组件),但共享库在多语言环境下就不一定行得通了。

五. 衡量架构的合理性

架构为业务服务,没有最优的架构,只有最合适的架构,架构始终以高效,稳定,安全为目标来衡量其合理性。

合理的架构设计:

5.1. 业务需求角度

  • 能解决当下业务需求和问题
  • 高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题
  • 前瞻性设计: 能在未来一段时间都能以第2种方式满足业务,从而不会每次当业务进行演变时,导致架构翻天覆地的变化。

5.2. 非业务需求角度

①. 稳定性。指标:

  • 高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

②. 高效指标:

  • 文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。
  • 可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。
  • 高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

③. 安全指标

  • 安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

常见架构误区

开高走落不到实处

  • 遗漏关键性约束与非功能需求
  • 为虚无的未来埋单而过度设计
  • 过早做出关键性决策
  • 客户说啥就是啥成为传话筒
  • 埋头干活儿缺乏前瞻性
  • 架构设计还要考虑系统可测性
  • 架构设计不要企图一步到位

常见误区

  • 误区1——架构专门由架构师来做,业务开发人员无需关注:架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。
  • 误区2——架构师确定了架构蓝图之后任务就结束了:架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。
  • 误区3——不做出完美的架构设计不开工:世上没有最好架构,只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车,而是从单轮车→自行车→摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?
  • 误区4—— 为虚无的未来埋单而过度设计:在创业公司初期,业务场景和需求边界很难把握,产品需要快速迭代和变现,需求频繁更新,这个时候需要的是快速实现。不要过多考虑未来的扩展,说不定功能做完,效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰,是应该适当的考虑未来的扩展性设计。
  • 误区5——一味追随大公司的解决方案:由于大公司巨大成功的光环效应,再加上从大公司挖来的技术高手的影响,网站在讨论架构决策时,最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路。
  • 误区6——为了技术而技术:技术是为业务而存在的,除此毫无意义。在技术选型和架构设计中,脱离网站业务发展的实际,一味追求时髦的新技术,可能会将技术发展引入崎岖小道,架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑,理想与现实需要折中。

架构知识体系

7.1. 架构演进

  • 初始阶段:LAMP,部署在一台服务器
  • 应用服务器和数据服务器分离
  • 使用缓存改善性能
  • 使用集群改善并发
  • 数据库地读写分离
  • 使用反向代理和cdn加速
  • 使用分布式文件和分布式数据库
  • 业务拆分
  • 分布式服务

7.2. 架构模式

分层:横向分层:应用层,服务层,数据层

分割:纵向分割:拆分功能和服务

分布式

  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算

集群:提高并发和可用性

缓存:优化系统性能

  • cdn
  • 方向代理访问资源
  • 本地缓存
  • 分布式缓存

异步:降低系统的耦合性

  • 提供系统的可用性
  • 加快响应速度

冗余:冷备和热备,保证系统的可用性

自动化:发布,测试,部署,监控,报警,失效转移,故障恢复

安全:

7.3. 架构核心要素

高性能:网站的灵魂

  • 性能测试
  • 前端优化
  • 应用优化
  • 数据库优化

可用性:保证服务器不宕机,一般通过冗余部署备份服务器来完成

  • 负载均衡
  • 数据备份
  • 自动发布
  • 灰度发布
  • 监控报警

伸缩性:建集群,是否快速应对大规模增长的流量,容易添加新的机器

集群

  • 负载均衡
  • 缓存负载均衡

可扩展性:主要关注功能需求,应对业务的扩展,快速响应业务的变化。是否做法开闭原则,系统耦合依赖

  • 分布式消息
  • 服务化

安全性:网站的各种攻击,各种漏洞是否堵住,架构是否可以做到限流作用,防止ddos攻击。

  • xss攻击
  • sql注入
  • csr攻击
  • web防火墙漏洞
  • 安全漏洞
  • ssl

原文

标签:架构 业务 系统
10分钟了解云原生 值得收藏~
« 上一篇 2022-05-20
如何在Bash脚本中使用强大的Linux测试命令
下一篇 » 2022-05-20
  • 胡迪核心知识点详解(好文章合集)
    1阅读 0条评论 个赞
    以下文章来源于公众号-3分钟秒懂大数据,作者在IT中穿梭旅行在Flink实时流中,经常会通过FlinkCDC插件读取Mysql数据,然后写入Hudi中。所以在执行上述操作时,需要了解……
  • 前端面试必须解决网络中的跨域问题
    0阅读 0条评论 个赞
    什么是跨域浏览器有一个重要的安全策略,称之为「同源策略」其中,源=协议+主机+端口源=协议+主机+端口源=协议+主机+端口,两个源相同,称之为同源,两个源不同,称之为跨源或跨域比如:源1源2是否同……
  • 如何在Bash脚本中使用强大的Linux测试命令
    0阅读 0条评论 个赞
    Linuxtest命令是Shell内置命令,用来检测某个条件是否成立。test通常和if语句一起使用,并且大部分if语句都依赖test。可以将一个元素与另一个元素进行比较,但它更常……
  • 10分钟了解云原生 值得收藏~
    0阅读 0条评论 个赞
    文章转载:奇妙的Linux世界我们已经进入云计算下半场,不再像上半场在纠结要不要上云,而是讨论怎么上云?才能把云计算的价值发挥到淋漓尽致。如何把云计算与不同的业务场景深度结合?如何让技术真正作用于企业……
  • 你可能不知道PostgreSQL能做的8件有趣的事!
    0阅读 0条评论 个赞
    1整行引用您是否尝试过运行以下语句?SELECTmy_tableFROMmy_table;这可能看起来很奇怪,但它所做的是将所有列作为行类型返回到单个列中。现在你为什么要这样做?好吧,您很可……
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
  • 数据治理 区分系统、机制、流程的概念很重要
    0阅读 0条评论 个赞
    以下文章来源于公众号-大鱼的数据人生,作者讨厌的大鱼先生我们刚接触数据的时候,从事的大多是具体的数据管理活动,无论是数据的采集、开发和开放,或是元数据管理、数据质量管理或是数据安全管理等等,但当你想更……
  • 甲骨文(第11代)单实例-室内空调(第11代)迁移模拟测试
    1阅读 0条评论 个赞
    Oracle11.2.0.4单实例----Oracle19C-RAC迁移模拟测试总体思想:通过RMAN物理备份在备库恢复主库数据,后续通过在主库停业务后,将从备份后的所有日志都同步到新库应用,重新配置……
  • 一天一技能:协调与多流程的完美结合
    7阅读 0条评论 个赞
    我们知道,协程本质上是单线程单进程,通过充分利用IO等待时间来实现高并发。在IO等待时间之外的代码,还是串行运行的。因此,如果协程非常多,多少每个协程内部的串行代码运行时间超过了IO请求的等待时间,那……
  • Java处理异常的9个最佳实践 你做得对吗?
    1阅读 0条评论 个赞
    原文:https://dzone.com/articles/9-best-practices-to-handle-exceptions-in-java译者:飒然Hang译文:http://www.r……
  • 10分钟了解云原生 值得收藏~
    0阅读 0条评论 个赞
    文章转载:奇妙的Linux世界我们已经进入云计算下半场,不再像上半场在纠结要不要上云,而是讨论怎么上云?才能把云计算的价值发挥到淋漓尽致。如何把云计算与不同的业务场景深度结合?如何让技术真正作用于企业……
  • 脸书数据库项目负责人:我从做基础设施中学到的42件事
    2阅读 0条评论 个赞
    最近读到了分布式系统研究者MaheshBalakrishnan的一篇博客《42thingsIlearnedfrombuildingaproductiondatabase》。同样做……
  • 如何在Bash脚本中使用强大的Linux测试命令
    0阅读 0条评论 个赞
    Linuxtest命令是Shell内置命令,用来检测某个条件是否成立。test通常和if语句一起使用,并且大部分if语句都依赖test。可以将一个元素与另一个元素进行比较,但它更常……
  • MySQL查询语句的准备阶段是什么?
    1阅读 0条评论 个赞
    以下文章来源于公众号--一树一溪,作者一树一溪这一篇主要讲的内容是一条简单查询语句,在查询准备阶段会干哪些事情?分3个部分:打开表select*替换为表字段填充where条件示例表及SQ……
  • 记得服务器被黑过一次 没想到能轻松搞定~
    1阅读 0条评论 个赞
    常在河边走,哪能不湿鞋。自认为安全防范意识不错,没想到服务器被入侵挖矿的事情也能落到自己头上。本文简要记录发现服务器被入侵挖矿的过程,同时分析木马的痕迹和信息,最后给出解决方法。服务器被入侵挖矿过程事……
  • MySQL的行格式是什么?
    1阅读 0条评论 个赞
    行格式(rowformat)决定了我们插入的一行数据,是如何存储在数据库中的,MySQL有4种行格式,分别是REDUNDANT,COMPACT,DYNAMIC,COMPRESSED。不同行格式区别:……
  • 基础巩固——至少需要多少行代码才能实现深度复制?
    1阅读 0条评论 个赞
    前言深度克隆(深拷贝)一直都是初、中级前端面试中经常被问到的题目,网上介绍的实现方式也都各有千秋,大体可以概括为三种方式:JSON.stringify+JSON.parse,这个很好理解;全量判断类……
  • 做SQL性能优化真的是干瞪眼
    1阅读 0条评论 个赞
    很多大数据计算都是用SQL实现的,跑得慢时就要去优化SQL,但常常碰到让人干瞪眼的情况。比如,存储过程中有三条大概形如这样的语句执行得很慢:selecta,b,sum(x)fromTgr……
  • 如何用10行bash shell脚本监控Linux?
    1阅读 0条评论 个赞
    http://985.so/xbtd子沐爱扫地(译)监控我们的环境对于服务器运维来说至关重要,尤其是在部署新的应用程序时。如今,公司每天都使用开源解决方案来监控系统资源。但是,当出于测试的目的来监控……
  • 不容错过的20个ES6技巧
    5阅读 0条评论 个赞
    前言大家好,我是xieyezi,好久不见,我又重新回归掘金啦,这次为大家整理了20个使用频率很高的ES6代码块,希望大家喜欢……
  • 高并发服务的几点优化经验
    1阅读 0条评论 个赞
    前言:如何优化高并发服务,这里指的是qps在20万以上的在线服务,注意不是离线服务,在线服务会存在哪些挑战呢?①无法做离线缓存,所有的数据都是实时读的②大量的请求会打到线上服务,对于服务的响应时间要……
  • 运维常用的34个Linux Shell脚本 对你一定有帮助!
    1阅读 0条评论 个赞
    作为一名Linux工程师,会写好的脚本不仅能提高工作效率,还能有更多的时间做自己的事。最近在网上冲浪的时候,也注意收集一些大佬写过的脚本,汇总整理一下,欢迎收藏,与君共勉!(1)用户猜数字#!/b……
  • 高可用性架构设计的无状态服务
    2阅读 0条评论 个赞
    笑谈架构设计事故的发生是量的积累的结果,任何事情都没有表面看起来那么简单,在软件运行的过程中,随着用户量的增加,不考虑高可用,迟早有一天会发生故障,不得事先考虑高可用设计,而高可用是一门庞大的学问。在……
  • 我用Java在几分钟内处理了30亿条数据.
    2阅读 0条评论 个赞
    来源:https://c1n.cn/GM8hb目录场景说明模拟数据场景分析读取数据处理数据遇到的问题场景说明现有一个10G文件的数据,里面包含了18-70之间的整数,分别表示18-70岁的……
  • 数据仓库实践:总线矩阵体系结构的设计
    1阅读 0条评论 个赞
    以下文章来源于公众号-云祁的数据江湖,作者云祁如何设计一套切实可行的数据仓库呢?我们要明白,对于数据仓库的设计是不能完全依赖于业务的需求,但往往又必须要服务于业务的价值。因此,在构建数据仓库前,我们……
  • 一行Python代码实现并行
    1阅读 0条评论 个赞
    译者:caspar译文:http://985.so/amks原文:http://985.so/amk5Python在程序并行化方面多少有些声名狼藉。撇开技术上的问题,例如线程的实现和GIL,我……
最近发布资讯
更多