Browsed by
标签:Dubbo

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

分布式定时任务调度框架实践

分布式定时任务调度框架实践

閱讀本文約花費: 14 (分鐘)分布式任务调度框架几乎是每个大型应用必备的工具,本文介绍了任务调度框架使用的需求背景和痛点,对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践,并分析了这几种框架的优劣势和对自身业务的思考。 一、业务背景 1.1 为什么需要使用定时任务调度 (1)时间驱动处理场景:整点发送优惠券,每天更新收益,每天刷新标签数据和人群数据。 (2)批量处理数据:按月批量统计报表数据,批量更新短信状态,实时性要求不高。 (3)异步执行解耦:活动状态刷新,异步执行离线查询,与内部逻辑解耦。 1.2 使用需求和痛点 (1)任务执行监控告警能力。 (2)任务可灵活动态配置,无需重启。 (3)业务透明,低耦合,配置精简,开发方便。 (4)易测试。 (5)高可用,无单点故障。 (6)任务不可重复执行,防止逻辑异常。 (7)大任务的分发并行处理能力。 二、开源框架实践与探索  2.1 Java 原生 Timer 和ScheduledExecutorService 2.1.1 Timer使用 Timer缺陷: Timer底层是使用单线程来处理多个Timer任务,这意味着所有任务实际上都是串行执行,前一个任务的延迟会影响到之后的任务的执行。 由于单线程的缘故,一旦某个定时任务在运行时,产生未处理的异常,那么不仅当前这个线程会停止,所有的定时任务都会停止。 Timer任…

Read More Read More

当我们谈注册中心时谈什么?

当我们谈注册中心时谈什么?

閱讀本文約花費: 11 (分鐘)最近工作重心转向了注册中心,于是想来写一篇关于注册中心的文章 概念 什么是注册中心,以大多数人熟悉的RPC框架来说,通常RPC中有三种角色: provider 服务提供者 consumer 服务消费者,即调用方 registry 注册中心,让consumer能发现provider的关键 注册中心对于服务提供者需要具备服务注册、注销的能力,对于服务消费者需要提供查询服务、感知服务变化的功能。当然还需要解决一些其他问题才能成为一个优秀的注册中心,如高可用、高性能、水平扩展能力、服务探活能力、路由功能、多机房(多活)能力等。 特性详解 存储 可以将注册中心理解为一个存储系统,存储着服务名与服务提供方的映射表。由此可见DNS是目前使用最广泛的注册中心。一般注册中心对存储没有什么要求,甚至你可以基于数据库来实现一个注册中心。 高可用 在聊高可用前,假定你了解分布式CAP理论,如果不知道可以稍微网上查一下,这里就不赘述。 其中对注册中心的高可用要求尤其高,它有如下几层含义,首先肯定是集群部署,无单点问题,其次就算整个集群挂掉了,也不能影响现有服务的调用,只不过现有的调用关系无法及时改变而已。 在分布式理论CAP中,注册中心更理想的应该是AP模式。(此结论更多讨论参考文末的《阿里巴巴为什么不用ZooKeeper做服务发现》),可以简单的从以下两个场景来理解:​ 注…

Read More Read More

阿里巴巴为什么不用 ZooKeeper 做服务发现?

阿里巴巴为什么不用 ZooKeeper 做服务发现?

閱讀本文約花費: 24 (分鐘)历史的迷思 站在未来的路口,回望历史的迷途,常常会很有意思,因为我们会不经意地兴起疯狂的念头,例如如果当年某事提前发生了,而另外一件事又没有发生会怎样?一如当年的奥匈帝国皇位继承人斐迪南大公夫妇如果没有被塞尔维亚族热血青年普林西普枪杀会怎样,又如若当年的丘老道没有经过牛家村会怎样? 2007年底,淘宝开启一个叫做“五彩石”的内部重构项目,这个项目后来成为了淘宝服务化、面向分布式走自研之路,走出了互联网中间件体系之始,而淘宝服务注册中心ConfigServer于同年诞生。 2008年前后,Yahoo 这个曾经的互联网巨头开始逐渐在公开场合宣讲自己的大数据分布式协调产品 ZooKeeper,这个产品参考了Google 发表的关于Chubby以及 Paxos 的论文。 2010年11月,ZooKeeper从 Apache Hadoop的子项目发展为 Apache的顶级项目,正式宣告 ZooKeeper成为一个工业级的成熟稳定的产品。 2011年,阿里巴巴开源Dubbo,为了更好开源,需要剥离与阿里内部系统的关系,Dubbo 支持了开源的 ZooKeeper 作为其注册中心,后来在国内,在业界诸君的努力实践下,Dubbo + ZooKeeper 的典型的服务化方案成就了 ZooKeeper 作为注册中心的声名。 2015年双11,ConfigServer 服…

Read More Read More

让开发部署提速8倍,我参与这款的插件的全过程

让开发部署提速8倍,我参与这款的插件的全过程

閱讀本文約花費: 20 (分鐘)如何像参与开源那样,去参与一款 IDE 插件的设计? 作为一款 IDE 插件的使用者,我是否能决定下一个版本的功能? 自从产品经理银时小伙和他的开发小哥们在去年12月发布 Cloud Toolkit(一款 IDE 插件)以来,已帮助数以万计的开发者们提高了业务的部署效率。期间,开发者们不仅是 Cloud Toolkit 的使用者,同时也作为设计者参与了插件的更新迭代。 本文来自开发者徐靖峰,分享了他和 Cloud Toolkit 的故事 遇见 Cloud Toolkit 在与中间件小姐姐的一次聊天中,偶然间了解到这款插件,小姐姐跟我提到自己正在运营一款 IDE 开发者工具,能够使开发部署效率提高 8 倍,出于好奇心,我就上手体验了一下,看看究竟是一个什么样的产品。使用了一段时间之后,便迫不及待地向小姐姐分享了我作为开发者对插件的一些看法。 我对这款产品最直观的感受:这是一款发布工具,帮助用户在 IDE 中直接打包应用并部署到各种终端。一开始看到这款产品位于阿里云的页面中,原本以为是一款和阿里云服务强绑定的产品,但试用过后才发现,即使对于普通的云主机,也非常适用,还可以解决很多开发运维的痛点,非阿里云用户可以放心使用。 在 Cloud Toolkit 出现之前 作为一个 Java 程序员,我们大多数会在 Intellij IDEA 中基于 S…

Read More Read More

浅谈服务治理与微服务

浅谈服务治理与微服务

閱讀本文約花費: 12 (分鐘)近期都在谈微服务,本人也正在做相关的工作,应领导要求做了一个微服务的分享,本篇文章主要来源于分享的PPT,所以有些简单,有问题可以在下面留言,大家 一起讨论。 本篇文章先简单介绍了互联网架构的演变,进而介绍了服务化,最后再介绍微服务,微服务是服务治理的升级也是互联网架构的进一步延伸。 互联网架构演变 一体架构 在计算机软件发展早期,一般桌面软件都是采用这种架构,不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构,但也可以说是很好的架构,因为它足够简单。 mvc架构 但随着浏览器的出现便产生了web应用,web应用的特点是界面部分是显示在浏览器中,服务处理是在服务容器中的,页面显示一般用css+js+html技术来处理,而后端可以用java、php等语言,这就产生了前后端分离。对于web系统,一体架构难以满足前后端分离的开发需求,因而便产生了MVC架构。 MVC才算的上真正意义上的架构,因为它除了解决了前后端分离问题,还引入了一种全新的开发模式,用一种业务逻辑、数据、界面显示分离的方法组织代码,使得整个应用层次更加分明,而且各个层次之间不但减低了耦合性,还提高了各个层次的可重用性。 但随着应用规模的不断扩大,应用模块不断增加,整个应用也显得越来越臃肿,维护起来也更加困难,因此便又产生了多应用架构。 多应用架构 多应用架构很简单,就是把…

Read More Read More

连接zookeeper时报”Path cannot be null”错误的解决方法

连接zookeeper时报”Path cannot be null”错误的解决方法

閱讀本文約花費: 3 (分鐘)   上周将公司生产环境中zookeeper集群中的一台zookeeper重启后,所有的连接此zookeeper的客户端都报如下错误: [ctvpay] 2018-03-23 10:57:08.569 — ERROR [main-EventThread] CuratorFrameworkImpl.java:529 – Watcherexceptionjava.lang.IllegalArgumentException: Path cannot be null        at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45) ~[zookeeper-3.4.6.jar!/:3.4.6-1569965]        at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1572) ~[zookeeper-3.4.6.jar!/:3.4.6-1569965]        at com.netflix.curator.framework…

Read More Read More

Zookeeper到底是干嘛的

Zookeeper到底是干嘛的

閱讀本文約花費: 17 (分鐘) Zookeeper主要哪些服务:配置管理,名字服务,提供分布式同步以及集群管理,更多介绍请看下文. 在Zookeeper的官网上有这么一句话:ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 这大概描述了Zookeeper主要可以干哪些事情:配置管理,名字服务,提供分布式同步以及集群管理。那这些服务又到底是什么呢?我们为什么需要这样的服务?我们又为什么要使用Zookeeper来实现呢,使用Zookeeper有什么优势?接下来我会挨个介绍这些到底是什么,以及有哪些开源系统中使用了。 配置管理 在我们的应用中除了代码外,还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式,在代码中引入这些配置文件。但是当我们只有一种配置,只有一台服务器,并且不经常修改的时候,使用配置文件是一个很好的做法,但是如果我们配置非常多,有很多服务器都需要这个配置,而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法,我们在这个集中的地方修改了配置,所有对这个配置感…

Read More Read More

微服务写的最全的一篇文章

微服务写的最全的一篇文章

閱讀本文約花費: 14 (分鐘) 本文来自于网络,本文主要讲解的是微服务,详细阐述了微服务的利弊、服务分层、微服务的服务发现的三种方式微服务的路由发现体系等相关知识。 今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可) 2)独立的进程(java的tomcat,nodejs等) 3)轻量级的通信(不是soap,是http协议) 4)基于业务能力(类似用户服务,商品服务等等) 5)独立部署(迭代速度快) 6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择) ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。 2. 怎么权衡微服务的利于弊 利: 强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活) 可独立部署。 技术多样性。 弊: 分布式复杂性。 最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题) 运维复杂性。 测试复杂性。 3. 企业在什么时候考虑引入微服务 从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的…

Read More Read More

代码,到底该如何分层,才能给人赏心悦目的感觉?

代码,到底该如何分层,才能给人赏心悦目的感觉?

閱讀本文約花費: 8 (分鐘)# 背景 说起应用分层,大部分人都会认为这个不是很简单嘛 就controller,service, mapper三层。看起来简单,很多人其实并没有把他们职责划分开,在很多代码中,controller做的逻辑比service还多,service往往当成透传了,这其实是很多人开发代码都没有注意到的地方,反正功能也能用,至于放哪无所谓呗。这样往往造成后面代码无法复用,层级关系混乱,对后续代码的维护非常麻烦。 的确在这些人眼中分层只是一个形式,前辈们的代码这么写的,其他项目代码这么写的,那么我也这么跟着写。但是在真正的团队开发中每个人的习惯都不同,写出来的代码必然带着自己的标签,有的人习惯controller写大量的业务逻辑,有的人习惯在service中之间调用远程服务,这样就导致了每个人的开发代码风格完全不同,后续其他人修改的时候,一看,我靠这个人写的代码和我平常的习惯完全不同,修改的时候到底是按着自己以前的习惯改,还是跟着前辈们走,这又是个艰难的选择,选择一旦有偏差,你的后辈又维护你的代码的时候,恐怕就要骂人了。 所以一个好的应用分层需要具备以下几点: 方便后续代码进行维护扩展; 分层的效果需要让整个团队都接受; 各个层职责边界清晰。 # 如何进行分层 1、阿里规范 在阿里的编码规范中约束的分层如下: 开放接口层:可直接封装 Service 方法暴露成 R…

Read More Read More

第四章 Sentinel–服务容错

第四章 Sentinel–服务容错

閱讀本文約花費: 30 (分鐘) 从高并发带来的问题的问题说起 ,讲解服务雪崩效应,常见容错方案,Sentinel基础,相关的应用规则等。 4.1 高并发带来的问题 在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。 接下来,我们来模拟一个高并发的场景 @[email protected] class OrderController2 {@Autowiredprivate OrderService orderService;@Autowiredprivate ProductService productService;@RequestMapping(“/order/prod/{pid}”)public Order order(@PathVariable(“pid”) Integer pid) {log.info(“接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息”, pid); //调用商品微服务,查询商品信息Product product = productService.find…

Read More Read More

第一章 微服务的架构介绍发展

第一章 微服务的架构介绍发展

閱讀本文約花費: 16 (分鐘) 微服务架构, 简单的说就是将单体应用进一步拆分,拆分成更小的服务,每个服务都是一个可以独立运行的项目。那么下文主要了微服务架构的发展,详情请看下文。 微服务介绍 1.1 系统架构演变 随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。 从互联网早起到现在,系统架构大体经历了下面几个过程: 单体应用架构—>垂直应用架构—>分布 式架构—>SOA架构—>微服务架构,当然还有悄然兴起的Service Mesh(服务网格化)。 接下来我们就来了解一下每种系统架构是什么样子的, 以及各有什么优缺点。 1.1.1 单体应用架构 互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这 样可以减少开发、部署和维护的成本。 比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块, 我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。 优点: 项目架构简单,小型项目的话, 开发成本低 项目部署在一个节点上, 维护方便 缺点: 全部功能集成在一个工程中,对于大型项目来讲不易开发和维护 项目模块之间紧密耦合,单点容错率低 无法针对不同模块进行针对性优化和水平扩展 1.1.2 垂直应用架构 随着访问量的逐渐增大,单一应用只能依靠增加节点来应…

Read More Read More

一文带你搞懂API网关

一文带你搞懂API网关

閱讀本文約花費: 19 (分鐘)前言 假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。 那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题: 每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。 如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名,另一方面是连接数的瓶颈,想象一下你打开一个APP,通过抓包发现涉及到了数百个远程调用,这在移动端下会显得非常低效。 每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。 另外还有一个问题,后端每个微服务可能是由不同语言编写的、采用了不同的协议,比如HTTP、Dubbo、GRPC等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工…

Read More Read More

Dubbo服务命令

Dubbo服务命令

閱讀本文約花費: 2 (分鐘)命令列表 进入shell终端连接服务命令: [shell]telnet ip 端口号 ,按回车键进入dubbo命令模式。[/shell] 查看服务列表命令: [shell] ls [/shell] [shell]ls[/shell] 查看服务详细列表: [shell]ls -l[/shell] 查看某个服务的方法列表: [shell]ls ***Service[/shell] 查看服务的方法的详细列表: [shell]ls -l ***Service[/shell] 调用服务的接口命令: [shell]invoke com.test.TestService.selectBuyId(‘name’)[/shell] 调用服务的方法: [shell]invoke ***Service.***Method(‘name’)[/shell] 查看状态列表: [shell]status -l[/shell] 退出当前telnet命令行: [shell]exit[/shell] 代码演示 命令行调用dubbo远程服务 telnet远程连接到dubbo [shell] [[email protected] ~]$ telnet 172.20.20.85 20888 Trying 172.20.20.85… Connect…

Read More Read More

Scroll Up