关于微服务学习的总结

这段时间一直在为了找工作学习,因为现在企业都要求会微服务,做为一个已经有5年开发经验的程序员,不会点微服务实在说不过去,所以为了找工作,还有加上自己的好奇,这段时间把为服务系统的学了一下。先看了网上的一期学习视频,看完后有了个感性的了解,知道了微服务springCloud是什么?解决什么样的问题?怎么使用?这些问题在脑海里基本有个模糊的答案,然后看了两本书《微服务设计》和《Spring Cloud微服务实战 》,吸收了一些内容,觉得有必要把学习到的总结一下。
 
关于什么是微服务?
“微服务是小而协同工作的自治服务”,作者这样定义。我谈谈我的理解,从字面上来讲“微服务”就是“小的服务”,"小"体现在服务在原来传统的单体应用上进行了拆分,大而化小,小而内聚,把原来在同一个应用的不同模块,拆分成了可以独立部署的服务,提高了独立性和降低了耦合性。“服务”这个词体现了服务治理,不是简单的各个模块拆开就成了微服务,拆分之后还需要有机的整合,能够很协调的一起工作,这样的才能算合格的微服务。相比传统单体应用而言,项目的个体是更小了,但是项目总体结构变庞大了,因此微服务有其利,有其弊,关于微服务的利弊后面谈谈。
 
微服务为什么会出现,解决了什么问题?
微服务是近五年内流行起来的概念,微服务的出现是伴随着我们的项目出现的问题给出的解决方案。传统的单体应用随着业务的发展、功能的升级、项目的迭代,代码可能变得越来越臃肿,越来越庞大,各模块间耦合度高不易扩展的问题,维护起来开发人员怨声载道等等,这时候要解决这些问题,需要把项目各个部分模块化,但是仅仅是项目内的模块化还是不能够解决根本问题,随着业务的调整变动还有可能会参和到一起,而且这种模块化各个功能单位还是在一个进程之内,一个功能引发的故障可能会殃及全池,整个系统瘫痪。所以解决这个问题需要更彻底的独立,各个模块独立一个进程、模块之间的交互以服务的形式接口调用,所以这个时候微服务应运而生。
 
微服务的优缺点
微服务给我们带来了“高内聚,低耦合”这些好处的同时也给带来了新的问题,下面说说我理解到的优缺点:
优点:
  • 减少耦合:更为彻底的模块化、组件化开发,减少系统耦合,易扩展;
  • 安全性:各个模块独立进程,避免相互影响;
  • 技术异构:各个模块可以针对不同的模块的业务特点选择不同的技术架构,甚至不同的语言;
  • 组织分工:有利于团队的分工,比如某个人或某几个人专门负责某个项目。
缺点:
  • 运维难度:系统架构上更庞大,从开发、测试、部署、运维都提出了新的要求,比单体应用复杂;
  • 故障概率:独立的项目增加同时也是增加了一个新的故障点,提高了故障概率,但是相对来说影响面减少了,这一点可以说两平了;
  • 服务性能:相对于单体应用进程内的方法调用,微服务之间的http或rpc调用方式成本更高。
结合以上对于一个大的项目微服务的方式还是优胜于劣,架构的复杂必然会带来维护的难度。
 
微服务的实现
微服务的实现不仅仅是开发的层面,包括架构、开发、测试和运维都需要调整。
 
1、服务划分
第一步需要进行服务的划分,服务的划分是很关键的一步,决定了服务之间是否能很协调的工作,划分的不好将来有很多很蹩脚的操作。
划分追求的目标是“高内聚,低耦合”,识别出业务边界,相同的功能组织在一起,保证服务之间的独立性,减少依赖。
划分的步骤是自上而下,先粗后细,先整体后局部。
 
2、技术集成
微服务涉及的技术很多,RPC、HTTP、RESTful 、消息队列、zookeeper、dubbo、springCloud等等,这些技术都是围绕着这几个方面的技术实现:
  • 服务间的通信:服务间可以采用HTTP或RPC通信,相对于RPC,HTTP更具有灵活性和技术兼容性,所以大部分的微服务都是采用HTTP通信;微服务的api更强调规范性,一般都采用RESTful规范。
  • 服务的注册和发现:服务注册和发现是微服务核心的部分,把分散的服务在这个层面统一起来。服务端向注册中心注册服务,客户端从注册中心获取服务清单调用对应服务端。这部分可以用zookeeper或eureka实现。
  • 服务的保护:服务间的调用相比进程内的方法调用更不稳定,所以需要提供一定的安全策略来应对这些风险,比如服务熔断、隔离和降级。
  • 服务的负载均衡:一个服务可以部署多个服务实例,使用负载均衡分担压力。
  • 服务路由和过滤:服务的调用如果需要有一个统一的入口进行服务的路由或过滤,这时候可以引入网关这个角色。
  • 服务的监控:监控服务的健康状态,并发量。
  • 服务的配置:项目被拆分成多个子项目后管理配置是一个难题,微服务需要更容易服务的配置,这时候配置中心这个角色出现了,使用配置中心可以统一管理服务的配置文件,配置文件可以放在一个git仓库,还可以区分不动的环境(开发、测试、生产)。
 
这些技术中dubbo和springCloud是一个微服务整体的框架,涵盖里微服务所需要的技术实现。dubbo是采用RPC调用,springCloud采用HTTP,相对来说springCloud更灵活、功能更全面丰富,是目前较dubbo更流行的框架。
 
3、单体应用的分解
从原来单体应用到微服务,改造是一个很庞大的工程,需要科学的规划,按一定步骤来,循序渐进。可以从项目内模块的分离-->数据库的分离-->项目的分离-->融合成微服务,这个过程实现。
  • 1)项目内模块的分离:先把项目模块做好拆分,每个模块独立的目录,注意模块间的接缝部分,避免过耦合。
  • 2)数据库的分离:数据库根据模块做好拆分,最好按模块独立一个数据库,公共的部分可以考虑一个公共的模块,将来独立的服务。数据库的分离也可以考虑分两个阶段,第一阶段实现同一个库,表按模块分离;第二阶段实现数据库分离。
  • 3)项目的分离:在模块已经分离的基础上把模块拎出来作为单独一个项目。
  • 4)融合成微服务:解决服务间的调用问题,引入微服务框架。
 
 
 
 
 
 
 
 

你可能感兴趣的:(关于微服务学习的总结)