用户您好!请先登录!

分类目录系统架构

分布式系统原理

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技术的衍化过程中早已提及。那么,细粒度更多的体现在”取其精华,去其糟粕”。

阅读更多

技术架构的战略和战术原则

技术架构,是将产品需求转变为技术实现的过程。技术架构解决的问题包括了如何进行纯技术层面的分层、开发框架选择、语言选择(这里以 JAVA 语言为主)、涉及到各自非功能性需求的技术点(安全、性能、大数据)。技术架构是确定组成应用系统实际运行的技术组件、技术组件之间的关系,以及部署到硬件的策略。

技术架构面临最大的挑战是“不确定性”。在技术架构上,很多时候就会面临这种选择。是要选择业界最新的技术?还是选择团队最熟悉的技术?如果选择最新的技术,遇到新技术出了问题怎么解决?如果选择目前熟悉的技术,后续技术演进怎么办?这些都是架构师在做技术架构过程中需要考虑的。

阅读更多

简谈Zookeeper基本原理

ZooKeeper简介

ZooKeeper是一个开放源码的分布式应用程序协调服务,它包含一个简单的原语集,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等。

java核心知识点整理—ZooKeeper基本原理

ZooKeeper设计目的

1.最终一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是zookeeper最重要的性能。

2.可靠性:具有简单、健壮、良好的性能,如果消息m被到一台服务器接受,那么它将被所有的服务器接受。

阅读更多

《重构》概要

1. 重构概述

1.1 重构的概念(What)

Refactoring

名词:对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低修改成本。

动词:使用一系列重构方法,在不改变软件可观察行为的前提下,调整其结构。

1.2 为什么要重构(Why)

改进软件设计

提高代码质量和可读性,使软件系统更易理解和维护

帮助尽早的发现缺陷

提高编程速度

阅读更多

从函数计算架构看Serverless演进

导读:云计算之所以能够成为 DT 时代颠覆性力量,是因为其本质是打破传统架构模式、降低成本并简化体系结构,用全新的思维更好的满足了用户需求。而无服务器计算(Serverless Computing)作为这个巨大市场的下一个阶段的进化产物,将真正帮助企业实现只专注于业务和构建应用程序,而不必担心 IT 基础设施,这也将成为云服务商未来竞争的关键。

什么是无服务器计算

云原生计算基金会(Cloud Native Computing Foundation, CNCF)对无服务器计算作了如下定义:

Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.

阅读更多

美图的数据平台架构演进

如今大数据在各行业的应用越来越广泛:运营基于数据关注运营效果,产品基于数据分析关注转化率情况,开发基于数据衡量系统优化效果等。

美图公司有美拍、美图秀秀、美颜相机等十几个 app,每个 app 都会基于数据做个性化推荐、搜索、报表分析、反作弊、广告等,整体对数据的业务需求比较多、应用也比较广泛。

因此美图数据技术团队的业务背景主要体现在:业务线多以及应用比较广泛。这也是促使我们搭建数据平台的一个最主要的原因,由业务驱动

1. 美图数据平台整体架构

如图所示是美图数据平台的整体架构。在数据收集这部分,我们构建一套采集服务端日志系统 Arachnia,支持各 app 集成的客户端 SDK,负责收集 app 客户端数据;同时也有基于 DataX 实现的数据集成(导入导出);Mor 爬虫平台支持可配置的爬取公网数据的任务开发。

阅读更多

Reactive编程详解 – 1

| 导语 反应式编程是在命令式编程、面向对象编程之后出现的一种新的编程模型,是一种以更优雅的方式,通过异步和数据流来构建事务关系的编程模型。本文包括反应式编程的概述和 RxPy 实战,以及怎样去理解反应式编程才能更好的把它融入到我们的编程工作中,把反应式编程变成我们手中的利器。

1. 反应式编程概述

1.1 背影趋势 

在 google 趋势中搜索反应式编程,可以看到其趋势在 2013 年后一直是往上走的。如图1所示:

640?wx_fmt=png

[ 图1 google 趋势搜索结果 ]

为啥呢?为啥是 2013 年才有明显的变化,因为2013 年后才有可以大范围使用的框架和库出现,才有人专门投入去布道反应式编程这个事情。

阅读更多

微服务不是银弹

大部分时候,微服务都是建立在一种基于请求和响应的协议之上。比如,REST等。这种方式是自然的。我们只需要调用另外一个模块就是了,然后等待响应返回,然后继续。这样的方式确实也满足了我们的很多的场景:用户通过点击页面的一个按钮然后希望发生一些事情。

但是,当我们开始接触许多独立的service的时候,事情就发生改变了。随着service数量急速的增长,同步交互比例也随着service在急速增长。这时候,我们的service就会遇到很多的瓶颈。

于是,不幸的ops工程师们就被我们坑了,他们疲惫的奔波于一个又一个的service,拼凑在一起的二手信息片段,谁说了什么,去往哪里,什么时候发生?等等。。。

这是一个非常典型的问题。市面上也有一些解决方案。一种方案就是确保您的个人服务具有比您的系统更高的SLA。 Google提供了这样做的协议。另一种方法是简单地分解将服务绑定在一起的同步关系。

阅读更多

云原生架构设计原则

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(TheTwelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。

阅读更多

如何应对随机杀死服务的“猴子”

Chaos Monkey:系统中的猴子

只要你有过在生产环境中实际运行过分布式系统的经历,你就应该清楚,各种不可预期的突发事件一定会发生。分布式系统天生包含大量的交互、依赖点,可以出错的地方数不胜数。硬盘故障、网络不通、流量激增压垮某些组件,我们可以一直列举下去。这都是每天要面临的常事儿,处理不好就会导致业务停滞,性能低下,或者是其他各种无法预期的异常行为。

在复杂的分布式系统中,人力并不能够阻止这些故障的发生,我们应该致力于在这些异常行为被触发之前,尽可能多地识别出会导致这些异常的,在系统中脆弱的,易出故障的环节。当我们识别出这些风险,我们就可以有针对性地进行加固,防范,从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹性(弹性:系统应对故障、从故障中恢复的能力)系统的同时,树立运行高可用分布式系统的信心。

阅读更多

用小内存来处理大规模数据

当你写了一个处理数据的软件,它可能在小样本文件上运行地很好,但一旦加载大量真实数据后,这个软件就会崩溃。

问题在于你没有足够的内存——如果你有 16GB 的 RAM ,你就无法一次载入 100GB 大小的文件。载入这么大的文件时,操作系统在某个时刻就会耗尽内存,不能分配存储单元,你的程序也就会崩溃。

所以,你该怎样防止这类情况发生?你可以启动一个大数据集群——你所需要做的是:

  • 搞到一个计算机集群。
  • 花一周时间搭建这个集群。
  • 大部分情况下,你需要学习一套全新的 API,重写你所有的代码。

这个代价可能很昂贵,会令人沮丧;幸运的是,大部分情况下,我们不必这样做。

你需要一个简单而容易的解决方案:在单机上处理你的数据,最小化环境搭建开销,尽可能利用你正在使用的代码库。实际上,大部分情况你都可以做到这样,只要使用一些方法即可,有时候这些方法被称为“核外计算”(out-of-core computation)。

本文将介绍如下内容:

  • 你究竟为什么需要 RAM。
  • 处理无法放入内存的数据最简单的方法:花些钱。
  • 处理大量数据的三种基本软件方法:压缩、分块、索引。

阅读更多

蚂蚁金服 Service Mesh 深度实践

1. 蚂蚁金服落地情况介绍

发展历程和落地规模

ppt-5.png

Service Mesh 技术在蚂蚁金服的落地,先后经历过如下几个阶段:

  • 技术预研 阶段:2017年底开始调研并探索 Service Mesh 技术,并确定为未来发展方向;
  • 技术探索 阶段:2018年初开始用 Golang 开发 Sidecar SOFAMosn,年中开源基于 Istio 的 SOFAMesh;
  • 小规模落地 阶段:2018年开始内部落地,第一批场景是替代 Java 语言之外的其他语言的客户端 SDK,之后开始内部小范围试点;
  • 规模落地 阶段:2019年上半年,作为蚂蚁金融级云原生架构升级的主要内容之一,逐渐铺开到蚂蚁金服内部的业务应用,并平稳支撑了618大促;
  • 全面大规模落地 阶段:2019年下半年,在蚂蚁金服内部的业务中全面铺开,落地规模非常庞大,而且准备迎接双十一大促;

阅读更多

隐藏在Arthas和CAT背后的动态代理技术

了解Spring中AOP的人都知道,其AOP实现原理是基于Java动态代理和CGLIB代理两种方式实现的,其实Java语言中除了上述两种外,还有其它三种实现技术,也是它们支撑着Arthas和CAT的底层核心原理:

  • 静态代理,工程师编辑代理类代码,实现代理模式;在编译期就生成了代理类。
  • 基于 JDK 实现动态代理,通过jdk提供的工具方法Proxy.newProxyInstance动态构建全新的代理类(继承Proxy类,并持有InvocationHandler接口引用 )字节码文件并实例化对象返回。(jdk动态代理是由java内部的反射机制来实例化代理对象,并代理的调用委托类方法)
  • 基于CGlib 动态代理模式 基于继承被代理类生成代理子类,不用实现接口。只需要被代理类是非final 类即可。(cglib动态代理底层是借助asm字节码技术
  • 基于 Aspectj 实现动态代理(修改目标类的字节,织入代理的字节,在程序编译的时候 插入动态代理的字节码,不会生成全新的Class )
  • 基于 instrumentation 实现动态代理(修改目标类的字节码、类装载的时候动态拦截去修改,基于javaagent) -javaagent:spring-instrument-4.3.8.RELEASE.jar (类装载的时候 插入动态代理的字节码,不会生成全新的Class )

阅读更多


1 2 3 4 5 6