文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

Netflix、亚马逊和一些其他公司已经在他们的产品中采用了微服务的概念,微服务是 软件行业中最热门的话题之一,有很多的组织想要采用它们。特别有用的事实是,用微服务能够使DevOps运作得很好。

但是什么是微服务?为什么一个组织应该采用它们?

为了了解它们,我们先看看完整的软件系统。

在一个完整的软件系统中,我们主要使用一个三层体系架构:

  • 表示层
  • 业务层
  • 数据访问层

假设有一个传统的网络应用客户(一个浏览器)提交了一个请求。业务层执行业务逻辑,数据库收集或储存应用明确的持久数据,最后,用户界面展现数据给使用者。

第 1 段(可获 1.5 积分)

然而,这种类型的体系存在几个问题。所有的代码(表示层、业务层和数据访问层)都被保存在同一个相同的代码库当中。虽然逻辑上来说,我们把服务比如JMS服器和数据访问服务区分开,但是它们存在于相同的代码库当中,当做一个简单的单元被部署。

即使我们创造一个多模型的设计,一个模型独立于另一个,进一步说, 在它的类路径中,这个模型需要一些可依靠的模型。虽然你使用的是一个分布式环境,但是它依然在同一个处理背景下运作。

因此,在一个单独的过程中,不同的服务之间相互交流。为了完成这个,在每一个应用容器中,所有的工件和它们的依赖库(jars)都是必须的。

第 2 段(可获 1.44 积分)

比如说jms service想要调用数据访问层。那么jms容器需要依赖数据访问层的jar包以及它所依赖的jar包(二级依赖)。

这种情况,会有很多痛点,而且架构设计上也不够灵活。

下面是你会面临的一些其他问题。

问题 1

由于共用一个代码仓库,这会导致代码逐渐增长。不管是UI开发还是业务开发,每一个开发人员都向这个代码仓库提交,这就导致了代码管理的低效。假设一个开发人员只关注jms模块,但是他需要把全部代码拉到本地然后配置各个模块才能把这个项目启动起来。太low逼了吧?本来他应该只关注jms模块,但现实情况并不允许他这么干。

 

第 3 段(可获 1.85 积分)

问题 2

由于只有一个代码仓库且各个模块之间相互依赖,导致任何一个模块,即使一个微小的改动,都会造成整个模块在整个分布式环境中都需要重新部署。

假设有一个多模块的项目,jms模块和业务模块依赖数据访问模块。在数据访问层一个简单的更改,那么我们就需要从新打包部署jms和业务模块。

问题 3

由于通常的软件采用3层架构,每一层架构有专门的team,且他们协同参与开发同一个功能。即使3层架构的设计允许隔离职责,但是长期来看,架构的层级边界会变的模糊最终失去灵活性。

第 4 段(可获 1.58 积分)

假设我们开发了一个库存管理功能.UI,业务层和数据访问层都有它们自己的工作.但每个人都想控制主体业务部分以便于出现缺陷时他们能解决这些缺陷而不依赖其它层的开发人员.由于这种竞争,各层的边界最终变得模糊,从而造成低效的架构.

问题4

我在许多项目中都看到有一个开发者团队和另一个支持团队.开发者团队只开发项目,并在项目发布后,将项目交接给支持团队.我个人是不支持这种文化的.尽管交接中涉及知识转移,但这并没有解决问题.对于某些至关重要的事情,支持团队不得不求助于开发者团队,但这会降低支持团队的可靠性.

第 5 段(可获 1.78 积分)

问题5

由于我们的系统非常大,所以我们的团队管理也一样非常复杂.一般情况下,我们基于层次创建团队----UI开发者团队,后端开发者团队,数据库程序员团队等等.他们在各自的领取都是专家,但他们几乎不懂其他层.所以当发生重大的事故时,这会牵扯每个层次,大家就开始推卸责任.不仅如此,发现出问题的层次和决定解决问题的人也会花费我们更多的时间.

Netflix和Amazon通过称为微服务的解决方案来解决这些问题.

微服务架构让我们将产品或项目拆分成独立的服务以便于仅在同一水平上部署和管理,同时不需要依赖依赖其他服务.

第 6 段(可获 1.54 积分)

看过这个概念后,就会有一个明显的问题。我应该基于什么来拆分我的项目?

很多人对微服务的认识并不正确。它并不是让你基于jms层,UI层,log层等等,这些层级来拆分项目。

上面的理解绝逼的错误的。反而我们应该按照功能来拆分。按照完整的功能,这个功能点可能包括了UI,业务逻辑,日志服务,jms,数据访问,jndi等等。

功能点之间需要被拆分开,不应该互相依赖。

 

第 7 段(可获 1.18 积分)

那么如果项目有库存,订单,计费,UI及购物车模块,我们可以将每个服务分解为独立部署的模块.每个模块拥有自己的维护,监控,应用服务器和数据库.看的出来,微服务没有中心数据库----每个模块有它自己的数据库.

并且这个数据库可以是关系型或NoSQL数据库.你可以根据模块按需选择.这就是混合持久化( polyglot persistence).

微服务文化最重要的一方面是哪个团队开发的服务,那个团队就有管理它的责任.这避免了交接概念及与之相关的问题.

 

第 8 段(可获 1.31 积分)

“微服务“ 的优点和缺点

Image title

Image title

优点 1

在一个独立的软件中, 你只是用一种语言开发,例如使用java作为基础代码. 但如果使用”微服务“,每一个服务都是独立的,并且每一个服务都是一个新的项目, 而且每一个服务都可以使用任何一种最符合项目需求的语言开发.

优点 2

开发者只需要把精力放在一个特定的服务中, 因此代码库会非常小,开发人员也会很好的理解这些业务代码(而不是庞杂的代码库,像某篇文章说他们的代码库像一座shit mountain). 

优点 3

当一个服务需要与另外的服务交互时,他们可以使用API,具体的说是使用 REST 风格的服务. REST风格的服务中和了项目沟通成本,因此稍加改造便可. 而不像 SOA, 一个微服务消息总线比一个ESB要精简的多, 因为它不需要过多的转换、分类以及路由选择.

第 9 段(可获 1.69 积分)

优点 4

没有中心数据库. 每个模块都是相互独立的,所以数据也是分散的. 你可以根据需要在你的模块中使用NoSQL或者其他关系型数据库, 关于这些内容我以前已经介绍过.

很多人以为SOA和”微服务“是同一种东西. 如果从定义上说,他们是长的很像, 但 SOA 是通过使用ESB用来在不同的系统中交互数据的), ESB在此过程中承担了很多管理数据,做分类等的工作. 

但”微服务“通过使用一条”静默消息总线“用来在服务与服务之间传递输入数据, 而且针对上述任务来讲,它的endpoint已经足够灵活. 它有”静默消息总线“和灵活的endpoint配置.

第 10 段(可获 1.46 积分)

在微服务通讯中使用REST,需要变换的范围很小— 仅仅是一个服务通过API调用来依赖另外一个服务。

但微服务也有缺点

因每个功能方面都是一个独立的个体服务, 所以在一个大项目,会有许多服务。监控这些服务增加一些了开销。

不仅如此,当有一个服务失败,跟踪调试将是一个艰苦的工作。

因为是服务间的调用,所以路径追踪并调试也会是很困难的。

每个服务会生成一个日志,因此没有中央日志监控。这将是很痛苦的,为此我们需要一个很好的日志管理系统。

第 11 段(可获 1.39 积分)

在微服务中,每个服务通过API /远程调用来进行通讯,相比单体的软件进程间通信来说它的开销要更大一些。

尽管有这些弊病,但微服务可以做真正的职责分离。  

第 12 段(可获 0.44 积分)

文章评论