欢迎来到快舔包我很肥的博客

白茶清欢无别事,我在等风也等你,三里春风三里路,步步清风再无你。
扩大
缩小

什么是微服务,微服务的思考和认知

近期看了杨波老师讲的《微服务》课程,深有感触,准备做下记录和学习笔记,希望能寻找到更多的一些方法论和思想进行微服务架构上的指引。

 

 

谈到微服务,有必要谈到两个人,这两个人对微服务架构的定义产生非常深远的影响,一个是马丁福勒,一个是netflix架构总监Adrian Cockcroft,netflix公司对整个微服务架构推进起到决定性的推进作用。其中马丁福勒在一篇博文中说了几个微服务定义的核心点,这里把它罗列出来。

 

 

第一个人马丁福勒认为微服务架构是一种架构风格,此架构风格包含了上图的六个特点

一组小的服务

原来的单块服务都是业务能力大而全的打包在一个单块中,微服务主张把这些单块服务进行拆分,形成一个个小的独立的服务。这里有个最大的特点是“小”,那么纠结要小到什么程度才为之小,很多同学都会纠结这个小的点,因为这个小并没有特别和明确的规定,所以这也就引申出了现在很多DDD领域驱动设计来指引微服务的拆分,但基本上一个微服务能让一个开发人员能够独立的理解,基本上就称为一个微服务,具体有多少行代码并不是很关键。

独立的进程

微服务是运行在独立的进程当中,例如java程序部署在tomcat,也可以部署在容器docker中,容易本身也是一种进程,所以微服务可以以进程的方式去扩展。

轻量级的通讯

微服务主张使用轻量级去构建通讯机制,例如http,固定消息格式和减少消息格式,服务之间不耦合,让通讯尽量轻量。

基于业务能力

微服务是基于业务能力进行构建,例如有用户服务,登陆服务,商品服务,基于这些业务能力去构建这些微服务。

独立部署

微服务被拆分开后,每个团队独立维护自己的微服务,开发,迭代自己的微服务,是可以独立的去部署,团队之间是不需要特别的去协调,这些对业务开发维护可以做到更加的敏捷,轻量,快速。

无集中式管理

原来单体服务是需要整个技术团队是需要独立的架构团队去管理,统一架构,统一技术栈,统一存储,微服务就不太一样,微服务主张每个团队根据自己的技术需要,选择自己最熟悉,最高效解决问题的技术栈,甚至选择不同存储方式。

说到第二个人netflix架构总监 Adrian Cockcroft,他给微服务下了一个定义 : "Loosely Coupled service oriented architecture with bounded context"

  • 首先第一点:服务之间应该是松散耦合,不能对周边有强依赖,如果一个团队的开发对周边有强依赖性,则不能认为松散耦合
  • 其实第二点:服务面向的架构,微服务还是在本质上无法脱离SOA的理念,本身来说还是一种SOA,只是更加细化落地。
  • 第三点:有界上下文,每个团队可以维护自己的数据源,不是集中式的数据源,每个团队可以自己独立去演化自己的数据源,对业务的支持会更加敏捷

思考点:

微服务可以独立部署,独立部署给业务带来什么的好处? 微服务是基于有界上下文,每个团队是可以拥有自己独立的数据源,但在分布式系统中每个团队拥有了独立的数据源会带什么挑战?

posted on 2019-07-26 10:14  快舔包我很肥  阅读(...)  评论(... 编辑 收藏

导航