你了解微服务架构么?

摘要:微服务架构最主要的两个特征:细粒度和独立,简单来讲微服务就是细粒度的独立的服务。这有什么好处呢?

微服务架构最主要的两个特征:细粒度和独立,简单来讲微服务就是细粒度的独立的服务。这有什么好处呢?

第一,细粒度就是每一个服务专注做好一件事情,每个服务完成一个单一任务。在功能不变的情况下,应用被分解为多个可管理的服务,很好的解决了复杂性问题。

第二,独立开发,独立测试,独立部署,独立更新。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度,快速的部署变化。因为是分布式的,微服务架构模式使得持续化部署成为可能。

从架构的角度来讲,微服务架构是相当于过去的单体架构来看的。过去是单体架构,虽然做到了SOA面向服务了,但是这些服务都只是分了模块,没有成为独立的服务,他们都是访问统一的数据库。在微服务架构里面这些服务都是独立部署的,服务是独立开发、测试、变更。这些服务都有自己的数据,这是微服务架构。

对比单体架构和微服务架构的区别:

  单体架构

在单体系统架构下做一个变更修改,不得不把整个系统重新部署一遍,这个时间周期会很长,而且牵一发动全身。

  微服务架构

而微服务架构,每个服务都可以独立的变更和部署。从应用架构的发展来看,最早的CGI,到MVC,到SOA,再到MSA。MSA跟SOA相比新的特征是什么呢?一是独立部署、快速迭代、持续交付。过去的SOA里面每一个模块不是独立部署的。

为什么一直强调独立部署很重要呢?

首先,因为独立部署可以做到快速迭代。持续交付,永远的测试版,这个系统没有完成时,永远在改,因为服务只要有新的需求时就快速变更,哪些服务不用了,让它休眠就完了,这样的话就可以做到持续的交付。

其次,独立部署可以做到只针对需要的部分进行扩展。比如说某一个功能用户大量在使用时,就把更多资源配给它。过去是整块的结构,只能基于整块进行扩展。现在当并发量很大时,只需要根据它的访问系统自动的把资源配给它。

再次,独立部署拥有自己的数据。每个服务都拥有自己的数据,给数据治理也带来了新的要求,推动实现去中心化的服务治理。

所以,单体架构更适合轻量级的简单应用。如果你用它来开发复杂应用,那真的会很糟糕。微服务架构模式则可以用来构建复杂应用。未来业务的敏捷一定要依赖于IT的敏捷,我们一直追求敏捷的IT:一个弹性可扩展的云计算与大数据基础平台(IaaS + PaaS),加上基于微服务架构的原生云应用(SaaS)开发,这已成为企业级IT的必然选择!

北达软信息化咨询与培训中心(国家信息资源管理北京研究基地)是一家专注于EA研究、咨询和培训的服务机构。成立于2006年,注册在北京大学科技园,通过了ISO9001质量体系认证。北达软最早将TOGAF、FEA、ESA和Archimate等企业架构认证培训引入中国。通过将EA与云计算、大数据、物联网和移动互联网等新IT技术的结合,北达软已形成一套完善的新IT架构或互联网架构设计与转型方法论。

本文转自d1net(转载)

时间: 2024-10-23 10:41:45

你了解微服务架构么?的相关文章

通过Ruby on Rails和docker构建微服务架构之入门教程

说到时下的架构,免不了会涉及到微服务.而谈到微服务架构,又跟容器和Docker技术脱不了关系.虽然容器和Docker并不完全是一回事,但两者是密不可分的,而且二者之间也有共同之处:在大型复杂应用的构建和运营方面,二者都可以大大提高企业的效率.   微服务可不像一般的应用,可以通过apt-get工具进行安装,大家可能会问了:我们该如何才能像安装应用一样实现这种服务呢?在很大的程度上,这个问题的答案是否定的,我们无法轻松实现这种服务.更准确的说,至少目前我们还无法实现.在一个系统中,最难修改的就是架

12年互联网产品开发人眼中的微服务架构云端应用

微服务架构很热,讨论的文章非常多.但如果提到微服务架构的云端应用,可以深入分析的还比较少.本篇来自中生代技术群(FreshmanTechnology)第二期,好雨云创始人兼CEO刘凡的分享.其曾任澳客网 CTO和CEO职位.拥有超过12年互联网产品开发和管理经验,专注于互联网技术架构设计,对产品设计.敏捷开发.安全.OKRs.大数据等领域有深入研究.现推崇反应式编程(http://www.reactivemanifesto.org/),并在多个产品中成功应用. 下为正文: 微服务架构(Micro

基于Nginx搭建一个安全的、快速的微服务架构

本文讲的是基于Nginx搭建一个安全的.快速的微服务架构[编者的话]本文改编自Chris Stetson发表在nginx.conf 2016上的一个有关如今的微服务以及如何使用Nginx构建一个快速的.安全的网络系统的演讲,大家可以在YourTube上回看此次演讲. 0:00 - 自我介绍 Chris Stetson:Hi,我的名字是Chris Stetson,我在Nginx带领专业服务部门,同时也领导微服务实践. 今天我们要谈论微服务以及如何使用Nginx构建一个快速的.安全的网络系统.在我们

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht

如何提高微服务架构的可用性

业界通常用多少个9来衡量系统的可用性,如99.99%表示一年中有1小时左右的不可用时间.任何一个服务的可用性都不会是100%,意味着在服务运行时间里还是有可能发生故障.当把功能集中且运行在同一个应用中的单体架构拆分成多个相互独立的微服务架构后,虽然可以降低一损俱损的全局性故障风险,但由于微服务之间存在大量的依赖关系, 随着微服务个数的增多,依赖关系也将会变得越来越复杂,而且每个微服务都有可能发生故障,如果不能做好相互依赖的隔离,避免故障的连锁反应,结果可能比单体更糟糕.假设有100个微服务,并且

微服务架构的理论基础 - 康威定律

概述 关于微服务的介绍,可以参考微服务那点事. 微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 .前段时间看了Mike Amundsen <远距离条件下的康威定律--分布式世界中实现团队构建>(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容. 可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且

Spring Boot与Docker(二):使用Spring Boot和Docker构建微服务架构

本文讲的是Spring Boot与Docker(二):使用Spring Boot和Docker构建微服务架构,[编者的话]本篇是<使用Spring Boot和Docker构建微服务架构>系列的第二篇,本篇我们将会利用工具进行设置,深入探讨如何使用Docker工作,然后搭建我们的第一个容器.原文作者为3Pillar环球旗下美国Adbanced技术集团的总监Dan Greene,Dan有十八年的软件设计和开发经验,包括在电子商务.B2B集成.空间分析.SOA架构.大数据以及云计算等领域的软件产品架

学霸君基于Docker的微服务架构设计

以下内容根据演讲PPT以及现场分享整理而成. 今天主要分享的是我们在实践微服务架构或者容器架构过程中踩过的坑,对于致力在容器技术方面进行探索的同学会有很大帮助.本次将站在整体的角度,分享如何去运维整个线上系统,如何看待整个微服务的架构.微服务能带来什么帮助以及微服务又有哪些缺点,还有重要的一点就是微服务架构如何去落地实施.虽然阿里云这样的服务商为我们做了大量的工作,但是将微服务架构真正地落地实施还需要做很多的工作.而对于任何技术而言,都是存在优缺点的,微服务架构也不是救世的良药. 一.学霸君的发

亿级流量电商详情页系统实战:缓存架构+高可用服务架构+微服务架构

<缓存架构+高可用服务架构+微服务架构>深入讲解了亿级流量电商详情页系统的完整大型架构.同时最重要的是,在完全真实的大型电商详情页系统架构下,全流程实战了整套微服务架构,包含了基于领域驱动设计进行微服务建模.Spring Cloud.基于DevOps的持续交付流水线与自动化测试套件.基于Docker的自动化部署.此外,还包含了大型电商详情页系统架构中的多种复杂架构设计的详细介绍. <亿级流量电商详情页系统实战(第一版)>的内容,主要是基于简化以后的大型电商详情页系统的背景,重点包含

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段