037 关于微服务的认识

  对于微服务,还是只是一个感性的理解,缺乏系统的整理。

  而且,读每一篇文章,都感觉有道理。这样就需要,先将人家比较好的文档列举,然后整理出自己文档。

一:一个简单的普通的理解,不涉及具体的技术

  一、什么是微服务?
  微服务架构风格是一种讲一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制,这些服务围绕业务能力构建并且可通过全自动部署机制独立部署,这些服务公用一个小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储。
  微服务具备以下的特性:

    每个微服务可独立运行在自己的进程里
    一系列独立运行的微服务共同构建起整个系统
    每个微服务为独立的业务开发,一个微服务只关注某个特定的功能
    微服务之间通过一些轻量级的通信机制进行通信
    可以使用不同的语言和数据存储技术
    全自动部署机制
  二、微服务的优点
    易于维护和开发:一个微服务只关注一个特定的业务功能,所以它业务清晰,代码量较少,开发和维护单个微服务相对简单
    单个微服务启动较快:单个微服务代码量少,所以启动较快
    局部修改容易部署
    技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点合理的选择技术栈
    按需伸缩:可根据需求实现细粒度的扩展
  三、微服务面对的挑战
    运维要求较高:更多的服务以为者更多的运维投入
    分布式固有的复杂性:使用微服务构建的是分布式系统,对于一个分布式系统,系统容错,网络延迟,分布式事物都会带来巨大的挑战
    接口调整成本高:微服务之间通过接口进行通信,如果修改某一个微服务的API,可能所有使用该接口的微服务都需要调整
    重复劳动:很多微服务都会使用到相同的功能,而这个功能还没有达到分解为一个微服务的程度,这个时候,可能各个服务会开发这一个功能而导致代码重复
  四、微服务设计的原则
    单一职责原则:单一职责是指一个单元(类,方法或者服务等)只应关注整个系统功能中单独有界限的一部分
    服务自治原则:服务自治原则是指每个微服务应具备独立的业务能力,依赖与运行环境
    轻量级通信原则:微服务之间应该通过轻量级的通信机制进行交互
    微服务粒度划分合理:微服务粒度是难点,应当使用合理的粒度划分微服务问不是一味的把服务做小,代码量的多少并不能作为微服务划分的依据,因为不同的微服务本身业务的复杂性不同,代码量也不同
  ---------------------
    作者:zhao_double_huan
    来源:CSDN
    原文:https://blog.csdn.net/weixin_41098980/article/details/79826986?utm_source=copy
    版权声明:本文为博主原创文章,转载请附上博文链接!

二:

1.微服务的由来

  微服务最早由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。

2.单体带来的问题

    单体架构在规模比较小的情况下工作情况良好,但是随着系统规模的扩大,它暴露出来的问题也越来越多,主要有以下几点:

  1.复杂性逐渐变高

  • 比如有的项目有几十万行代码,各个模块之间区别比较模糊,逻辑比较混乱,代码越多复杂性越高,越难解决遇到的问题。

  2.技术债务逐渐上升

  • 公司的人员流动是再正常不过的事情,有的员工在离职之前,疏于代码质量的自我管束,导致留下来很多坑,由于单体项目代码量庞大的惊人,留下的坑很难被发觉,这就给新来的员工带来很大的烦恼,人员流动越大所留下的坑越多,也就是所谓的技术债务越来越多。

  3.部署速度逐渐变慢

  • 这个就很好理解了,单体架构模块非常多,代码量非常庞大,导致部署项目所花费的时间越来越多,曾经有的项目启动就要一二十分钟,这是多么恐怖的事情啊,启动几次项目一天的时间就过去了,留给开发者开发的时间就非常少了。

  4.阻碍技术创新

  • 比如以前的某个项目使用struts2写的,由于各个模块之间有着千丝万缕的联系,代码量大,逻辑不够清楚,如果现在想用spring mvc来重构这个项目将是非常困难的,付出的成本将非常大,所以更多的时候公司不得不硬着头皮继续使用老的struts架构,这就阻碍了技术的创新。

  5.无法按需伸缩

  • 比如说电影模块是CPU密集型的模块,而订单模块是IO密集型的模块,假如我们要提升订单模块的性能,比如加大内存、增加硬盘,但是由于所有的模块都在一个架构下,因此我们在扩展订单模块的性能时不得不考虑其它模块的因素,因为我们不能因为扩展某个模块的性能而损害其它模块的性能,从而无法按需进行伸缩。

3.微服务与单体的区别

  1. 单体架构所有的模块全都耦合在一块,代码量大,维护困难,微服务每个模块就相当于一个单独的项目,代码量明显减少,遇到问题也相对来说比较好解决。
  2. 单体架构所有的模块都共用一个数据库,存储方式比较单一,微服务每个模块都可以使用不同的存储方式(比如有的用redis,有的用mysql等),数据库也是单个模块对应自己的数据库。
  3. 单体架构所有的模块开发所使用的技术一样,微服务每个模块都可以使用不同的开发技术,开发模式更灵活。

4.微服务与SOA

  微服务,从本质意义上看,还是 SOA 架构。但内涵有所不同,微服务并不绑定某种特殊的技术,在一个微服务的系统中,可以有 Java 编写的服务,也可以有 Python编写的服务,他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关,扩展性强。

5.微服务的目的

  微服务的目的是有效的拆分应用,实现敏捷开发和部署 。

6.什么样的项目适合使用微服务

  微服务可以按照业务功能本身的独立性来划分,如果系统提供的业务是非常底层的,如:操作系统内核、存储系统、网络系统、数据库系统等等,这类系统都偏底层,功能和功能之间有着紧密的配合关系,如果强制拆分为较小的服务单元,会让集成工作量急剧上升,并且这种人为的切割无法带来业务上的真正的隔离,所以无法做到独立部署和运行,也就不适合做成微服务了。

  能不能做成微服务,取决于四个要素:

  • 小:微服务体积小,2 pizza 团队。
  • 独:能够独立的部署和运行。
  • 轻:使用轻量级的通信机制和架构。
  • 松:为服务之间是松耦合的。

7.微服务的拆分与设计

  

原文地址:https://www.cnblogs.com/juncaoit/p/9785449.html

时间: 2024-10-19 11:02:51

037 关于微服务的认识的相关文章

用友iuap云运维平台支持基于K8s的微服务架构

什么是微服务架构? 微服务(MicroServices)架构是当前互联网业界的一个技术热点,业内各公司也都纷纷开展微服务化体系建设.微服务架构的本质,是用一些功能比较明确.业务比较精练的服务去解决更大.更实际的问题.该架构强调的一些准则:单一职责.协议轻量.进程隔离.数据分离.独立部署.按需伸缩. 什么是Kubernetes? Kubernetes是Google开源的容器集群管理系统,其提供应用部署.维护. 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,其主要功能:

初识微服务

1.背景 在云场景下,突变已经成为一种常态. 突变包括3个情形: 1. 业务突变 2. 流量突变 3. 应用故障 微服务能够敏捷应对以上情形. 2. 什么是微服务 微服务是一种架构模式,而并不是架构本身.微服务提倡围绕业务构建服务,把单体应用拆分成功能单一的服务,每个服务运行在一个进程中,服务间通过轻量级机制(restful)进行通信.并且可以独立进行开发,部署,运维. 3. 微服务缺点 1)  分布式系统本身的复杂性: 数据一致性等 2) 进程内通信变成网络通信,性能有损耗

创建微服务?请先回答这10个问题

原文地址:http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=401654497&idx=1&sn=5cac9aa4ae113592e1513c1ff70ea917&scene=21#wechat_redirect 乍一看微服务似乎很容易构建,但是要真正构建微服务,要完成的工作可比在容器里运行一些代码,并在这些代码间使用HTTP请求进行通信,要多得多.在开发新的微服务之前--必须得在新服务部署到生产环境之前--你需要回答

使用Ratpack和Spring Boot打造高性能的JVM微服务应用

使用Ratpack和Spring Boot打造高性能的JVM微服务应用 这是我为InfoQ翻译的文章,原文地址:Build High Performance JVM Microservices with Ratpack & Spring Boot,InfoQ上的中文地址:使用Ratpack与Spring Boot构建高性能JVM微服务. 在微服务天堂中Ratpack和Spring Boot是天造地设的一对.它们都是以开发者为中心的运行于JVM之上的web框架,侧重于生产率.效率以及轻量级部署.他

微服务架构

互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小公司在开始技术选型时感觉某个框架费时费力就不会选择,而小公司发展到大公司的过程,一般也伴随着系统不断优

深解微服务架构:从过去,到未来|架构(2015-07-15)

随着用户需求个性化.产品生命周期变短,微服务架构是未来软件软件架构朝着灵活性.扩展性.伸缩性以及高可用性发展的必然方向.同时,以Docker为代表的容器虚拟化技术的盛行,将大大降低微服务实施的成本,为微服务落地以及大规模使用提供了坚实的基础和保障. 微服务的诞生   微服务架构(Microservice Architect)是一种架构模式,它提倡将单块架构的应用划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟

微服务 - 文章

[微服务与容器的监控 —— 来自Adrian Cockcroft的挑战][http://www.infoq.com/cn/news/2015/07/monitoring-microservices]Adrian Cockcroft在GlueCon 2015大会上为听众列举了如何对微服务与基于容器的应用进行监控的多条规则.他还重强调了在监控cloud native并且基于容器的系统时所面临的挑战,并介绍了微服务模拟与可视化工具“Spigo” [微服务的好处][http://www.infoq.co

孢子框架-接口访问层、ESB、微服务API GateWay对比

如果从百度去搜索“接口访问层”你会发现主要是.NET里面的技术,叫做IDAL,其实是数据访问层接口.它的主要作用是兼容多种数据库.比如你定义一个标准接口,然后实现改接口的SqlServer访问和Oracle访问,那么利用IDAL就可以自由切换数据库.看.NET DEMO PetShop4,总共有22个项目.大体思想是3层,从Model.DAL.BLL,然后他在各层上又采用了工厂模式,把逻辑与实现想分离,比如以前BLL直接调用DAL就好了,但现在BLL却调用了IDAL,IDAL就是一个接口层,里面

腾讯正式对外开源高性能 RPC 开发框架与微服务平台Tars

Tars 是将腾讯内部使用的微服务架构 TAF(Total Application Framework)多年的实践成果总结而成的开源项目,目前已于4月10日正式对外开源. 作为支持多语言的高性能 RPC 开发框架和配套一体化的服务治理平台,Tars可以帮助企业或者用户以微服务的方式快速构建稳定可靠的分布式应用,它的设计灵感来源于采取分层思想,实现开发与运营之间的分离.目前该框架在腾讯内部,已经在 160 多个业务(如手机浏览器.应用宝.手机管家.手机QQ.手机游戏等).1.6 多万台服务器上运行