分布式系统的那些事儿(七) - 微服务架构体系

微服务的出现,标志了又一个新的里程碑,似乎你不知道微服务就代表你好像out了一样。微服务是业务服务化,将SOA更好的延续了下去。配合restful也能够更好的提供api接口。

简单来说就是微服务把各种各样的小的服务区分开来当做一个当度的应用跑在服务器上,并且他的通信机制也是十分简单的,使用rest或者rpc都行。他们可以各自对自己的业务进行处理。各个服务直接可以用不同的语言开发,这样提高了不同技术团队之间的职能。

微服务的特点:

1、微服务的组件是以服务的形式存在的。

2、由各个不同的业务来切分整个大服务。

3、微服务是产品,不是项目。微服务在整个开发生命周期十分长久,并且需要后期团队的维护,就是因为微服务的特性,才使得维护更加的方便。

4、简单的通信机制,不论是rpc还是restful,都简化了系统服务之间的访问,并不像曾经的wsdl那么复杂。

5、分散治理,这个就是跟传统巨石应用区别开来了。不同的服务都是一个很小的组件,那么在组装的时候不同的服务可以组装成不同的微服务,十分灵活。

6、数据库分散管理,在做巨石应用的时候,一个项目就是访问一个数据库。那么微服务不是,每个不同的业务访问并且管理的都是自己的数据库,与各个不同的服务之间的数据库是不同的,这样也做到了数据的隔离。

7、容错性,每个服务宕掉不可访问的时候,微服务可以为每个服务进行监控与恢复。

 

其实我们平时接触的最多的还是SOA,SOA是偏向系统的解决方案,而微服务面向服务,微服务的颗粒度要小很多,SOA比较大,哪怕是一个小更新其实也是要重启对应的系统,而微服务却不是。考虑一下玩王者荣耀的时候,可以不停机更新,是不是一个道理?

 

​SOA的缺点:

随着时间的推移,代码库会越来越大,如果团队来了一个新人是十分恐惧的。

开发工具也会随着代码量的增多变得缓慢,这样导致的就算是开发效率的降低。

服务器启动变慢,代码变多,容器在加载的时候读取的代码文件也越多,这样导致容器每次启动都会比较慢。

持续部署相对复杂,不利于运维更新。每次更新整个系统必须关闭,用户无法访问。

可扩展性降低。

 

微服务的特点:

各服务之间通过json或者xml的数据形式通信。把一组类似的功能或者业务作为一个单独的微服务来做。比如订单服务让订单核心团队来维护。cms由cms团队来维护。

服务之间通过rest或者rpc来通信,甚至使用消息队列。

服务独立开发和部署,相互不影响,技术只能部门也相互不影响。

服务之间相互解耦,每个服务都有自己对应的数据库。注意,这需要做好数据一致性,比如tcc。

每个服务独立部署,对于频繁更新版本的项目由很好的效率。

便于扩展团队和组织架构。

整个微服务相对技术难度比SOA加大,需要开发人员对技术有一定的持续投入。

分布式事务比单体应用难处理。

生产环境部署复杂度提升,需要运维人员有一定的功底。

 

微服务的难点:

很多初创型公司对于开发进度是十分有要求的,起初并不会使用微服务架构,而是单体应用或者SOA,为的是更好更快速的发展自身的业务。然而发展到一定规模后,整个技术架构发生变化,要重构为微服务,这个时候的技术选型以及如何重构,和整个团队技术人员的参与就相对来说是个难点了。

时间: 2024-11-14 12:37:48

分布式系统的那些事儿(七) - 微服务架构体系的相关文章

七牛容器SDN技术与微服务架构实践

     Docker的横空出世很大程度上推动了容器技术的热度和发展.容器技术和传统的虚拟化技术有很大的不同,具体包括:首先是相对于传统的虚拟机,以前一个虚拟机里做的事情,要打散成很多个容器去做,它们各自的职能会更少:第二点是会造成以前一个虚机的IP会变成很多个容器的多个IP,容器之间的关系会变得更加复杂:第三点是整个网络中的网络端点数量呈现一个上升的趋势:第四点是容器的生命周期其实会更短.此外,容器由于其轻量级的优势,可能会被不停地调度,从一台机器调度到另外一台机器,根据资源的负载均衡,容器的

微服务实践(七):从单体式架构迁移到微服务架构

本文讲的是微服务实践(七):从单体式架构迁移到微服务架构,[编者的话]这是用微服务开发应用系列博客的第七篇也是最后一篇.第一篇中介绍了微服务架构模式,并且讨论了微服架构的优缺点:接续文章讨论了微服务架构不同方面:使用API网关,进程间通信,服务发现,事件驱动数据管理以及部署微服务.本篇,我们将探讨将应用从单体式架构迁移到微服务架构需要考虑的策略. 希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂单体式应用,

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

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

微服务实战(一):微服务架构的优势与不足

本文讲的是微服务实战(一):微服务架构的优势与不足,[编者的话]本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战.正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足. 这篇文章作者是Chris Richardson,他是早期基于Java的Amazonite EC2 PaaS平台CloudFoundry.com的创始人.现在他为企业提供如何开发和部署应用的咨询服务.他也经常在http://microservice

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

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

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

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

老司机的微服务架构实现,照亮你的人生 | 朱攀

编者按:前2月,向朱攀兄弟约稿,畅聊甚欢,引为知己.今刊发以飨读者! 微服务为当今群雄混战局面,从dubbo问世数载,然业界尚未有完整打包结局方案,前有小剑之<老司机带你玩PPmoney微服务>,德比软件作为前驱,集数年研究与实战,搭建平台,填埋深坑,则业界之幸! 适逢1024程序员节,一并祝各位程序猿/媛节日快乐,早日步入老司机行列 前言 微服务概念被提出来后,短时间内就成了当前互联⽹圈的⼀个技术热点,有很多互联⽹公司计划或正在进⾏微服务化改造,那么,实施微服务我们应该怎么开始呢?需要哪些基

如何构建微服务架构

本文讲的是如何构建微服务架构[编者的话]"微服务"的概念兴起于四五年前,近几年尤其火热,各大厂都在进行微服务化改造和微服务建设.最近一年来我们也参与了微服务化的改造大军,这里写下一些做微服务系统设计和开发时的切身感受. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的 CI/CD 实践:开发流程中引入 CI.CD:Gitlab 和 C

微服务架构的优势与不足

微服务正在博客.社交媒体讨论组和会议演讲中获得越来越多的关注,在Gartner的2014 Hype Cycle上它的排名非常靠前.同时,软件社区中也有不少持怀疑论者,认为微服务不是什么新东西.Naysayers认为这就是SOA架构的重新包装.然 而,尽管存在着不同的争论,微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助. 首先我们看看为什么要使用微服务. 开发单体式应用 假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件,经过初步会议和需求分析,你可能会手动或者使用基