用户您好!请先登录!

分类目录系统架构

架构杂谈

什么是架构

架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案,架构往往是对复杂形态的一种共性的体系抽象。

业务架构体系是针对企事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案,更确切的说,是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统,比如业务架构体系认为一个信息系统必须由组织机构、业务流程、业务信息、业务功能、和业务语义等层次构成。

复杂系统集成的关键,是基于架构(或体系)的集成,而不是基于部件(或组件)的集成。

阅读更多

事件驱动架构中的RabbitMQ和Kafka选择

如果你问自己是否Apache Kafka比RabbitMQ更好或RabbitMQ是否比Apache Kafka更可靠,我想在这里阻止你。本文将从更广泛的角度讨论这两种情况。它关注的是这两个系统提供的功能,并将指导您做出正确的决定,决定何时使用哪个系统。

web上的一些文章让Apache Kafka在RabbitMQ面前大出风头,而另一些文章则恰恰相反。我们中的很多人可能会因为听了大肆宣传,跟着人群跑而认罪。我觉得重要的是要知道是使用RabbitMQ还是Kafka取决于您项目的需求,只有当您在合适的场景中使用了正确的设置,才能进行真正的比较。

阅读更多

领域驱动设计简介

今天的企业应用程序无疑是复杂的,并依赖一些专门技术来完成它们的工作。作为开发人员,我们倾向于关注这些技术细节是可以理解的。但事实是,一个不能解决业务需求的系统对任何人都没有用,无论它看起来多么漂亮或者如何很好地构建其基础设施。

领域驱动设计(DDD)的理念 – 首先由Eric Evans在他的同名书[1]中描述 – 是关于将我们的注意力放在应用程序的核心,关注业务领域固有的复杂性本身。我们还将核心域(业务独有)与支持子域(通常是通用的,如金钱或时间)区分开来,并将更多的设计工作放在核心上。

域驱动设计包含一组用于从域模型构建企业应用程序的模式。在您的软件生涯中,您可能已经遇到过许多这样的想法,特别是如果您是OO语言的经验丰富的开发人员。但将它们一起应用将允许您构建真正满足业务需求的系统。

阅读更多

六边形架构

六边形架构的思想是将输入和输出都放在设计的边缘部分。不管我们公开的是 REST 还是 GraphQL API,也不管我们从何处获取数据——是通过数据库、通过 gRPC 还是 REST 公开的微服务 API,或者仅仅是一个简单的 CSV 文件——都不应该影响业务逻辑。

这种模式让我们能将应用程序的核心逻辑与外部的关注点隔离开来。核心逻辑隔离后,意味着我们可以轻松更改数据源的细节,而不会造成重大影响或需要在代码库重写大量代码

另外,在应用中具有清晰边界的另一大优势就是测试策略——我们的大多数测试在验证业务逻辑时,都不需要依赖那些很容易变化的协议。

阅读更多

面向数据的架构

面向数据的架构(Data-Oriented Architecture)由 Rajive Joshi在RTI 的2007 年白皮书中首次提出,而维也纳大学(University of Vienna)的Christian Vorhemus 和Erich Schikuta 在2017 年的 iiWAS 论文中又再次对其进行了描述。 DOA 是对传统二分法的颠覆,它介于单体架构和微服务(Microservices)、面向服务的架构(Service-Oriented Architecture)之间。单体架构由一个单体二进制文件(binary)和数据存储组成;微服务、面向服务的架构由许多小型的、分布式的、独立的二进制文件组成,并且每个二进制文件都有自己的数据存储。在面向数据的架构中,单体数据存储是系统中状态的唯一来源,并由松耦合无状态的微服务对其进行操作。

阅读更多

Gartner:首份机器人流程自动化(RPA)魔力象限

作者:Derek Miers、Marc Kerremans、Saikat Ray和 Cathy Tornbohm

随着企业组织想方设法提高运营效率,并将遗留系统与新的企业应用软件和数字化业务集成,机器人流程自动化(RPA)继续扩大其应用范围。我们在本文中研究这些市场力量和提供此类软件的领先企业供应商。

市场定义/描述

机器人流程自动化(RPA)是一种数字化赋能技术,主要充分利用用户界面(UI)和表面级特征这对组合来创建自动处理常规性、可预测的数据转录工作的脚本。

RPA工具可将应用软件连接起来,消除输入错误,加快流程,并降低成本。RPA市场仍然比较小,2018年总收入略低于8.5亿美元。然而,RPA是Gartner正式跟踪分析的增长速度最快的软件领域,2018年同比增长超过63%。

阅读更多

DDD and CQRS Landing

这篇文章假设你已经初步了解过领域驱动设计(DDD)的基本概念(聚合根、实体、值对象、领域服务、领域事件、资源库、限界上下文等)以及CQRS的设计,这里将重点放在如何落地DDD和CQRS上。

DDD分层架构

Evans在它的《领域驱动设计:软件核心复杂性应对之道》书中推荐采用分层架构去实现领域驱动设计:

Spring中BeanDefinition那点事(上)

常言道,温故而知新。

BeanDefinition是什么?

我们先看官网上是怎么解释的:

从上文中,我们可以得出以下几点结论:

  1. BeanDefinition包含了我们对bean做的配置,比如XML<bean/>标签的形式进行的配置
  2. 换而言之,Spring将我们对bean的定义信息进行了抽象,抽象后的实体就是BeanDefinition,并且Spring会以此作为标准来对Bean进行创建
  3. BeanDefinition包含以下元数据:一个全限定类名,通常来说,就是对应的bean的全限定类名。bean的行为配置元素,这些元素展示了这个bean在容器中是如何工作的包括scope(域,我们文末有简单介绍),lifecycle callbacks(生命周期回调,下篇文章介绍)等等这个bean的依赖信息一些其他配置信息,比如我们配置了一个连接池对象,那么我们还会配置它的池子大小,最大连接数等等

阅读更多

微服务设计前的几个指导原则

对于从微服务开始的团队来说,最大的挑战之一就是坚持 金发女孩原则(The Goldilocks principle)(该典故来自于童话《金发姑娘和三只熊》):不要太大,不要太小,不能太紧密耦合。之所以是挑战的部分原因是会对究竟什么是设计良好的微服务感到疑惑。

数十位 CTO 通过采访分享了他们的经验,这些对话说明了设计良好的微服务的五个特点。本文将帮助指导团队设计微服务。(有关详细信息,请查看即将出版的书籍 Microservices for Startups ,LCTT 译注:已可免费下载完整的电子版)。本文将简要介绍微服务的边界和主观的 “规则”,以避免在深入了解五个特征之前就开始指导您的微服务设计。

微服务边界

使用微服务开发新系统的核心优势 之一是该体系结构允许开发人员独立构建和修改各个组件,但在最大限度地减少每个 API 之间的回调数量方面可能会出现问题。根据 SparkPost 工程副总裁 Chris McFadden 所说,解决方案是应用适当的服务边界。

阅读更多

PostgreSQL for Serverless (ServerlessDB)

不久前,腾讯云发布了国内第一款 Serverless 数据库 —— PostgreSQL for Serverless(ServerlessDB),在业界受到众多数据库开发者的广泛关注,它基于 PostgreSQL 数据库实现按需分配资源,能够做到安全隔离、弹性扩容、按需付费、原生 SQL 支持。在本文中,腾讯云 ServerlessDB 产品负责人从租户隔离技术、快速扩缩容能力、连接池管理等方面,详细解密这款数据库背后的设计细节,希望能够为所有开发者带来启发。

如何实现真正的自动扩缩容?

相比较于传统数据库,云数据库的弹性扩缩容和按量计费能够帮助用户按需使用云资源,避免资源浪费的同时大幅节省了成本。在系统实现原理上,目前云数据库提供的这类“弹性方案”本质上是一种策略上的弹性,即开发者需要先行预估自己的产品负载量,例如一款游戏什么阶段玩家特别多,什么时候人潮回落,在设定好数据库需求的方案后,对应进行手动的容量调整。

阅读更多

绕不开的软件架构基本原则

解决方案架构师是负责系统架构以及特定产品的技术标准(包括技术、平台、基础架构)的专家。他们为产品设定前景,他们的分析也是产品的定义、设计、交付和永久支持的成功关键。因此,构架师不仅需要了解业务需求,还需要了解符合企业技术总目标的逻辑性、可扩展性及成本效益。

架构师的重要技能之一就是能从许多不同的角度来看待架构,因为每一个单独的角度可能不完全相关,但结合在一起就可以从总体的角度来看待产品。这些角度包括原则、标准、模式和反模式、经验法则和经验实践,而这些对于决策方向确定和项目评估成功至关重要。

阅读更多

SpringBoot的埋点监控应用

JVM应用度量框架Micrometer实战

spring-actuator做度量统计收集,使用Prometheus(普罗米修斯)进行数据收集,Grafana (增强ui)进行数据展示,用于监控生成环境机器的性能指标和业务数据指标。一般,我们叫这样的操作为”埋点”。SpringBoot中的依赖spring-actuator中集成的度量统计API使用的框架是Micrometer,官网是Micrometer.io。

在实践中发现了业务开发者滥用了Micrometer的度量类型Counter,导致无论什么情况下都只使用计数统计的功能。这篇文章就是基于Micrometer分析其他的度量类型API的作用和适用场景。

Micrometer提供的度量类库

Meter是指一组用于收集应用中的度量数据的接口,Meter单词可以翻译为”米”或者”千分尺”,但是显然听起来都不是很合理,因此下文直接叫Meter,理解它为度量接口即可。Meter是由MeterRegistry创建和保存的,可以理解MeterRegistry是Meter的工厂和缓存中心,一般而言每个JVM应用在使用Micrometer的时候必须创建一个MeterRegistry的具体实现。

阅读更多

分布式系统原理

1 概念

1.1 模型

节点

在具体的工程项目中,一个节点往往是一个操作系统上的进程。在本文的模型中,认为节点是一个完整的、不可分的整体,如果某个程序进程实际上由若干相对独立部分构成,则在模型中可以将一个进程划分为多个节点。

异常

  1. 机器宕机:机器宕机是最常见的异常之一。在大型集群中每日宕机发生的概率为千分之一左右,在实践中,一台宕机的机器恢复的时间通常认为是24 小时,一般需要人工介入重启机器。
  2. 网络异常:消息丢失,两片节点之间彼此完全无法通信,即出现了“网络分化”;
    消息乱序,有一定的概率不是按照发送时的顺序依次到达目的节点,考虑使用序列号等机制处理网络消息的乱序问题,使得无效的、过期的网络消息不影响系统的正确性;
    数据错误;不可靠的TCP,TCP 协议为应用层提供了可靠的、面向连接的传输服务,但在分布式系统的协议设计中不能认为所有网络通信都基于TCP 协议则通信就是可靠的。
    TCP协议只能保证同一个TCP 链接内的网络消息不乱序,TCP 链接之间的网络消息顺序则无法保证。

阅读更多

Istio 1.5 发布后的变化

Istio 1.5 发布——拥抱变化,爱上单体

北京时间 2020 年 3 月 6 日凌晨,我们期待已久的 Istio 1.5 发布了,发布公告见 https://istio.io/news/releases/1.5.x/announcing-1.5/。由 ServiceMesher 社区组织翻译的 Istio 官方文档同时发布,见 https://istio.io/zh。

Istio 1.5 是一个具有重大变革的版本。长久以来,面对社区对 Istio 的性能和易用性的诟病,Istio 团队终于正视自身的问题,在当前版本中彻底推翻了原有控制平面的架构,完成了重建。正如 Simplified Istio 文中所说:

复杂是万恶之源,让我们停止焦虑,爱上单体。

阅读更多

微服务架构解耦设计详解

耦合性,是对模块间关联程度的度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。

模块间联系越多,其耦合性越强,同时表明其独立性越差。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。高内聚低耦合,是软件工程中的概念,是判断设计好坏的标准,主要是面向对象的设计,主要是看类的内聚性是否高,耦合度是否低。

SpringCloud和Dubbo都是现在比较成熟的微服务框架,如何使用两者构建搭建你的微服务系统呢?他们是如何将你的系统解耦的?

我仅用10步,就写出了全网最全的微服务架构详解

阅读更多

领域驱动设计(DDD)简介

今天的企业应用程序无疑是复杂的,并依赖一些专门技术(持久性,AJAX,Web服务等)来完成它们的工作。作为开发人员,我们倾向于关注这些技术细节是可以理解的。但事实是,一个不能解决业务需求的系统对任何人都没有用,无论它看起来多么漂亮或者如何很好地构建其基础设施。

领域驱动设计(DDD)的理念 – 首先由Eric Evans在他的同名书[1]中描述 – 是关于将我们的注意力放在应用程序的核心,关注业务领域固有的复杂性本身。我们还将核心域(业务独有)与支持子域(通常是通用的,如金钱或时间)区分开来,并将更多的设计工作放在核心上。

域驱动设计包含一组用于从域模型构建企业应用程序的模式。在您的软件生涯中,您可能已经遇到过许多这样的想法,特别是如果您是OO语言的经验丰富的开发人员。但将它们一起应用将允许您构建真正满足业务需求的系统。

阅读更多

Spring Cloud Gateway 2.0

为什么很多人觉得spring cloud gateway难用?因为它的背后用的是webflux,涉及到响应式编程,而不是传统的过程式编程。

我们把背后的技术梳理一下,不难发现,这个晦涩的根源,就来自于project reactor,与spring项目并驾齐驱的,”面向未来”的响应式编程框架。

结果最后的代码,都长的和lambda一样。其背后的思想,是观察者模式和非阻塞杂交的产物,学习曲线相对陡峭

万字Spring Cloud Gateway2.0,面向未来的技术,了解一下?

阅读更多

分布式缓存设计那点事

在高并发的分布式的系统中,缓存是必不可少的一部分。没有缓存对系统的加速和阻挡大量的请求直接落到系统的底层,系统是很难撑住高并发的冲击,所以分布式系统中缓存的设计是很重要的一环。下面就来聊聊分布式系统中关于缓存的设计以及过程中遇到的一些问题。

缓存的收益与成本

使用缓存我们得到以下收益:

  • 加速读写。因为缓存通常是全内存的,比如Redis、Memcache。对内存的直接读写会比传统的存储层如MySQL,性能好很多。举个例子:同等配置单机Redis QPS可轻松上万,MySQL则只有几千。加速读写之后,响应时间加快,相比之下系统的用户体验能得到更好的提升。
  • 降低后端的负载。缓存一些复杂计算或者耗时得出的结果可以降低后端系统对CPU、IO、线程这些资源的需求,让系统运行在一个相对资源健康的环境。

阅读更多

「无服务器架构」Knative Eventing

Knative Eventing是一个旨在满足云原生开发的常见需求的系统,并提供可组合的原语以启用后期绑定事件源和事件使用者。

设计概述

Knative Eventing是围绕以下目标设计的:

  1. 原始事件服务是松散耦合的。这些服务可以在各种平台上(例如Kubernetes,VM,SaaS或FaaS)独立开发和部署。
  2. 事件生产者和事件消费者是独立的。任何生产者(或源)都可以在有活动的事件使用者监听之前生成事件。在有生产者创建事件之前,任何事件消费者都可以对事件或事件类别表示兴趣。
  3. 可以将其他服务连接到Eventing系统。这些服务可以执行以下功能:创建新的应用程序而无需修改事件生产者或事件使用者。从生产者那里选择事件的特定子集并将其作为目标。
  4. 确保跨服务的互操作性。 Knative Eventing与由CNCF Serverless WG开发的CloudEvents规范一致。

阅读更多

白话微服务架构

微服务是什么?

微服务是一种细粒度(Fine-Grain)的SOA

或许在座的高朋了解过其概念。个人认为,与其说微服务是一种技术,不如将其定义为一种架构,而架构则是"技"的实现与"术"的策略相辅相成。
"术"的策略需要分析使用场景,进行合理地划分业务边界,实现"业以类聚",然而"技"的实现则通过特定的技术在实现业务逻辑之时,更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性,达到"技以群分"的目的。

由此而论,我个人偏好将其定义为:”微服务是一种细粒度的SOA”。

这样定义的好处在于,没必要去重复地”抹黑””单体应用”(Monolithic,也有人翻译成”巨石应用”),缘于SOA技术的衍化过程中早已提及。那么,细粒度更多的体现在”取其精华,去其糟粕”。

阅读更多


1 2 3 4 5 6