Browsed by
标签:架构

云和虚拟化有何区别?[云计算]

云和虚拟化有何区别?[云计算]

閱讀本文約花費: 6 (分鐘) 由于虚拟化和云的核心理念都是从抽象资源中创建可用的环境,所以很容易被混为一谈。虚拟化是一种技术,可让用户以单个物理硬件系统为基础,创建多个模拟环境或专用资源。而云是一种能够抽象、汇集和共享整个网络中的可扩展资源的 IT 环境。简而言之,虚拟化是一项技术,而云是一种环境。 人们创建云通常是为了进行云计算,也就是在系统中运行工作负载。  云基础架构可以包含各种裸机、虚拟化或容器软件,它们可用于抽象、汇集和共享整个网络中的可扩展资源,以此来创建云。稳定的操作系统(如 Linux®)是云计算的基础。这一层架构可让用户独立于公共、私有和混合环境之间。 如果您能访问内部网和/或互联网,则可以使用虚拟化来创建云,但这不是唯一的选择。  通过虚拟化,虚拟机监控程序会监控物理硬件,并抽象机器中各项资源,之后把这些资源提供给叫做虚拟机的虚拟环境。这些资源可以是原始处理能力、存储或基于云的应用,其中包含了部署所需的所有运行时代码和资源。 如果就此停止,则不能叫做云——这仅仅是虚拟化。  只有向中央池分配了虚拟资源,才能被称为“云”。增加一层管理软件后,即可管控将在云中使用的基础架构、平台、应用和数据。再增加一层自动化工具,用来替换或减少人工操作可重复指令和流程,从而为云提供自助服务组件。 如果您建立的 IT 系统满足以下条件,则说明…

Read More Read More

为什么在做微服务设计的时候需要DDD?

为什么在做微服务设计的时候需要DDD?

閱讀本文約花費: 9 (分鐘) 记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢?』 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性。但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可。 回到主题,我们要了解的是微服务和DDD到底有什么关系呢? 因为在互联网时代,软件所面临的问题域比以往要复杂得多,这种复杂性来源于不断扩展的问题域自身,也来源于创新变化,以及这种规模性增长所带来的挑战。 然而一个人一个团队,他对复杂的事物的认知是有极限的,面对这种复杂问题唯一的方法就是分而治之。分主要考虑的是如何去分;治意味着分出来的每一个部分要能够独立的运行,能够互相的协作,完成整体的目标,能够一来应对外部变化所带来的冲击。 微服务的缺陷 微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践,那微服务是不是解决复杂问题的银弹呢?其实不然,很多团队在应用了微服务架构来构建他们的系统以后,发现并没有完全解决这种复杂性问题,甚至还带来了一些其他的问题。比如: 服务并没有解决复杂系统如何应对需求变化这个问题,甚至还加剧了这个问…

Read More Read More

微服务划分的姿势

微服务划分的姿势

閱讀本文約花費: 10 (分鐘) 我们知道微服务是一种理念,没有确切的定义和边界,好比设计原则,是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话,具体问题需要具体分析,所以这篇文章谈到的划分也不是绝对标准,仅供参考。 有人说微服务不难,难的是服务的划分,虽然我持保留意见,但是从侧面也反应了划分具有一定的困难。这里的矛盾在于粒度,如果粒度太大了,分和不分似乎都差不多;如果粒度太小了,聚合、发布、调用链、调试等都是坑。 以下谈到的拆分是前人经验的总结,我罗列了三种行家的拆分姿势,每个的的经验和视野不同,各有偏颇,我在这里更多的是谈共鸣和感受,希望对你有所启发。 拆分姿势 姿势一:新浪微博微服务专家胡忠想从纵横两个维度来划分,简单粗暴。 纵向拆分 从业务维度进行拆分。标准是按照业务的关联程度来决定,关联比较密切的业务适合拆分为一个微服务,而功能相对比较独立的业务适合单独拆分为一个微服务。 横向拆分 从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。 纵向以业务为基准,关系铁的在一起;横向功能独立的在一起。我想如果拆分这么简单,你有底气拆,敢拆吗?所以我们又继续比对一下其他专家的言论。 姿势二:阿里的小伙伴从综合的维度来看,部分维度和上面会有重合 服务拆分要迎合业务的需要 充分考虑业务独立性和专业性,避免以团队来定义服务边界,…

Read More Read More

推荐的五款市面上常用的免费CMS建站系统

推荐的五款市面上常用的免费CMS建站系统

閱讀本文約花費: 11 (分鐘) 小乔做设计也有不少年头了,很多客户或者朋友找我做网站的时候,一般问我的是用什么软件系统给他们做。大部分客户希望用的软件是免费的。 所以今天小乔给大家介绍五款我自己用过还不错的,重点是还免费的建站系统。 MetInfo MetInfo这个系统是一个客户指定的,让我必须用这个系统给他做网站。于是我花了一些时间去了解这个系统。整个系统可操作性还是可以的。 MetInfo的框架是基于PHP+Mysql开发的。 从界面上来说,界面简洁一目了然,比较符合现在的用户习惯,扁平化的设计还是比较吸引用户的。从功能上来说,MetInfo功能基本齐全,常用的内容管理、多语言等基本功能都配备了。从使用上来说,一些版块的设计不是很人性化,藏得比较深,所以在使用的过程中会经常找不到,比较花时间。不过熟悉之后就好很多了。整体来说相对让我觉得系统比较出色的应该就是SEO这块,可设置的内容还是比较多的,seo效果也比较明显。总的来说,简单的界面设计还是很适合新手的。 主要的缺点就是技术服务跟不上,打400电话一直占线,qq上的技术服务又一直排队,问完一个问题再问一个qq技术服务直接没有响应。再来,小编没用过MetInfo的收费版,很多收费用户反映升级还要单独收费,这个收费标准可能还是存在一定的问题。 框架:PHP+Mysql架构 功能:会员、安全、营销、SEO、内容、移动端、多语言…

Read More Read More

SpringCloud Alibaba——服务注册与发现(Nacos)

SpringCloud Alibaba——服务注册与发现(Nacos)

閱讀本文約花費: 5 (分鐘) 一、Nacos简介 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 安装Nacos 下载地址(版本:0.7.0) Linux:sh startup.sh? Windows:startup.cmd? 访问:http://127.0.0.1:8848/nacos,可以进入Nacos的服务管理页面: 二、SpringCloud整合Nacos 完成了Nacos服务的安装和启动之后,下面就可以编写两个应用(服务提供者与服务消费者)来验证服务的注册与发现了。 spring cloud的版本以及spring cloud alibaba的版本,由于spring cloud alibaba还未纳入spring cloud的主版本管理中,所以需要自己加入,添加依赖文件(父工程): <properties><java.version>1.8</java.version><spring-cloud.version>Finchley.RELEASE</spring-cloud…

Read More Read More

第十章 Seata–分布式事务

第十章 Seata–分布式事务

閱讀本文約花費: 19 (分鐘) 接上文,系列文章的最后一篇了,本文主要介绍了分布式事务的基础,场景,以及分布式事物的解决方案,最后对Seata进行了介绍。 10.1 分布式事务基础 10.1.1 事务 事务指的就是一个操作单元,在这个操作单元中的所有操作最终要保持一致的行为,要么所有操作都成功,要么所有的操作都被撤销。简单地说,事务提供一种“要么什么都不做,要么做全套”机制。 10.1.2 本地事物 本地事物其实可以认为是数据库提供的事务机制。说到数据库事务就不得不说,数据库事务中的 四大特性: A:原子性(Atomicity),一个事务中的所有操作,要么全部完成,要么全部不完成 C:一致性(Consistency),在一个事务执行之前和执行之后数据库都必须处于一致性状态 I:隔离性(Isolation),在并发环境中,当不同的事务同时操作相同的数据时,事务之间互不影响 D:持久性(Durability),指的是只要事务成功结束,它对数据库所做的更新就必须永久的保存下来 取大写首 字母 也就是 简称 ACID 数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元,该执行单元中的所有操作要么都成功,要么都失败,只要其中任一操作执行失败,都将导致整个事务的回滚 10.1.3 分布式事务 分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位…

Read More Read More

第九章 Nacos Config–服务配置

第九章 Nacos Config–服务配置

閱讀本文約花費: 8 (分鐘) 本文介绍微服务架构下关于配置文件的一些问题,Nacos Config入门及深入,nacos的几个概念等,更多请看下文。 9.1 服务配置中心介绍 首先我们来看一下,微服务架构下关于配置文件的一些问题: 配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统一配置和管理。 配置文件无法区分环境。微服务项目可能会有多个环境,例如:测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的,一旦需要修改,就需要我们去各个微服务下手动 维护,这比较困难。 配置文件无法实时更新。我们修改了配置文件之后,必须重新启动微服务才能使配置生效,这对一 个正在运行的项目来说是非常不友好的。 基于上面这些问题,我们就需要配置中心的加入来解决这些问题。 配置中心的思路是: 首先把项目中各种配置全部都放到一个集中的地方进行统一管理,并提供一套标准的接口。 当各个服务需要获取配置的时候,就来配置中心的接口拉取自己的配置。 当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来同步最新的信息,使之动态更新。 当加入了服务配置中心之后,我们的系统架构图会变成下面这样: 在业界常见的服务配置中心,有下面这些: Apollo Apollo是由携程开源的分布式配置中心。特点有很多,比如:配置更新之后可以实时生效,…

Read More Read More

第七章 Rocketmq–消息驱动

第七章 Rocketmq–消息驱动

閱讀本文約花費: 16 (分鐘) 接上文,本文主要介绍了MQ是什么,及它的应用场景,消息发送和接收演示以及相关的案例。 7.1 MQ简介 7.1.1 什么是MQ MQ(Message Queue) 是一种跨进程的通信机制,用于传递消息。通俗点说,就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后,需要发送注册邮件和短信通知,以告知用户注册成功。传统的做法如下: 此架构下注册、邮件、短信三个任务全部完成后,才返回注册结果到客户端,用户才能使用账号登录。但是对于用户来说,注册功能实际只需要注册系统存储用户的账户信息后,该用户便可以登录,而后续的注册短信和邮件不是即时需要关注的步骤。 所以实际当数据写入注册系统后,注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果,由消息队列 MQ 异步地进行这些操作。架构图如下: 异步解耦是消息队列 MQ 的主要特点,主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时,由于使用了消息队列MQ,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦合。 7.1.2.2 流量削峰 流量削峰也是消息队列 MQ 的常用场景,一般在秒杀或团队抢购(高并发)活动中使用广泛。…

Read More Read More

第六章 Sleuth–链路追踪

第六章 Sleuth–链路追踪

閱讀本文約花費: 11 (分鐘) 本文介绍微服务架构中最重要的设计模式:微服务之间的数据通讯。更多请看全文。 6.1 链路追踪介绍 在大型系统的微服务化构建中,一个系统被拆分成了许多模块。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。在这种架构中,一次请求往往需要涉及到多个服务。 互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心,也就意味着这种架构形式也会存在一些问题 于是就出现了下面几个 问题 如何快速发现问题? 如何判断故障影响范围? 如何梳理服务依赖以及依赖的合理性? 如何分析链路性能问题以及实时容量规划? 分布式链路追踪(Distributed Tracing),就是将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪 台机器上、每个服务节点的请求状态等等。 常见的链路追踪技术有下面这些: cat 由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控 。 集成方案是通过代码埋点的方式来实现监控,比如: 拦截器,过滤器等。 对代码的侵入性很大,集成成本较高。风险较大。 zipkin 由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时…

Read More Read More

第五章 Gateway–服务网关

第五章 Gateway–服务网关

閱讀本文約花費: 15 (分鐘) 接上一篇文章开始网关之旅,首先告诉大家网关是什么,Gateway简介,怎么配置,怎么入门,执行流程等等相关介绍。 大家都都知道在微服务架构中,一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢?如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去 用。 这样的架构,会存在着诸多的问题: 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证复杂,每个服务都需要独立认证。 存在跨域请求,在一定场景下处理相对复杂。 上面的这些问题可以借助API网关来解决。 所谓的API网关,就是指系统的统一入口,它封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、路由转发等等。 添加上API网关之后,系统的架构图变成了如下所示: 我们也可以观察下,我们现在的整体架构图: 在业界比较流行的网关,有下面这些: Ngnix+lua 使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用 lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本 Kong 基于Nginx+Lua开发,性能高,稳定,有多个可用的插件(限流、鉴权等等)可以开箱即用。问题: 只支持Http协议;二次开发,自由扩展困难;提供管理API,缺乏更易用…

Read More Read More