美文网首页技术干货程序员
鲜驰达项目之第三次重构--微服务之微服务架构阐述

鲜驰达项目之第三次重构--微服务之微服务架构阐述

作者: 撸二行代码 | 来源:发表于2016-06-11 16:35 被阅读0次

    前言:记得上次XCD项目第二次重构的时候,是以模块为主,将每一个业务模块切分出来,对于共通的代码实现或者SQL的编写没有实现通过接口调用,而是通过Spring AOP根据Package来定义数据源。当初的设想是,可以将每一个模块进行独立部署,但是因为没有去调研自动发布等工具,导致发布需要手动改动Pom文件,而放弃模块独立发布的初衷。这样就导致第二次重构的设想有一些失败。只是单一的将代码切分开。

    为什么要进行微服务重构。

    在阐述为什么要用进行为服务重构的时候,需要介绍什么是为服务,为什么会选择微服务。

    什么是微服务:其实对于未服务的定义,也没有什么唯一的标准定义,就像NoSQL一样,我们一直在讨论,我们也知道大致的NoSQL的含义,也可以根据不同的场景使用NoSQL,但是如果让我们给NoSQL一个准确的定义,其实很难。其实微服务也想NoSQL一样没发给出一个完全定义。但是最近看书了解到,ThoughtWork的首席科学家--马丁 福勒(Martin Fowler)先生,对于微服务的定义,似乎比较容易理解:

    微服务架构师一种架构模式,它是倡导将单一应用程序划分为一组小的服务,服务之间互相协调工作,互相配合,为用户提供最终的价值。每一服务运行在其独立的进程中,服务和服务之间采取轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每一个服务都围绕着具体业务进行构建,并且能够独立地部署到生产环境,类生产环境等。另外,应尽量避免统一的,集中式服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言,工具对其进行构建。

    在进行XCD项目第二次的重构中,其实个人已经想进行模块化进行分组件,可惜也只是个人意愿,但是当找到一个可以说的来的伙伴的时候,这个计划就提上日程了,并且付之行动了。第三次重构。独立服务,将每一个业务功能模块进行服务化,这个就是微服务。这就是为什么要选择微服务。当你要进行为微服务组件的时候,首先你要你有一个或者二个赞同你的人,并且愿意和你一起付之行动和思考。并且一起考虑微服务你需要的各种技术点攻破。

    微服务多微才够微

    微服务架构是通过特定业务领域的分析和构建的,并且将负责的应用分类成一个个小并且专一,耦合度地并且可以高度自治的一组服务,每一个服务都是一个很小的应用,那么微服务中提到的微,到底什么样的“微”才是真正的微呢?

    其实讨论“微”的话,是一个很长的话题,这里我只是进行个人理解进行说明:

    微:不是代码级别的微,而是业务基本的。举一个🌰:订单,但是订单里面包含了各种复杂的模块。会和钱挂钩,会和库存挂钩,会和配送挂钩,会和收货挂钩。那么怎么切分这个微。其实正如一句老话“适合自己团队的才是最好的”。这个没有一个标准。但是我个人是会按照模块进行划分。订单就是订单,付款就是付款,库存就是库存。每一个是一个独立的。

    微服务的独立性

    微服务的独立性,在于我们一个个业务模块上线的时候,一个个模块都是一个独立的应用或者叫做服务,我们不必关心之前的服务,我们只要把这个新上线的服务进行开发,测试,部署就可以了。

    用二张图进行说明:

    耦合度高

    其实看这张图的时候,我往往醉了,因为这个就是我第二次改版的最后结果。

    独立性高

    其实这个就是现在的架构,我们保证每一个服务都是独立的,即使我业务发生变化,但是我对于的API接口参数还是不变的。也只是我服务内部发生变化。

    说了这么多,其实大家会发现我们的一起是围绕着服务进行架构的。那么为什么不用SOA呢?

    微服务和SOA

    其实微服务不是一个全新的概念,你会发现他的很多理念和SOA一致。

    SOA和微服务比较

    微服务的本质

    本质,指本身的形体,本来的形体;指事物本身所固有的根本的属性。语出晋刘智《论天》:“言闇虚者,以为当日之冲,地体之荫,日光不至,谓之闇虚。凡光之所照,光体小於蔽,则大於本质。”本质可使人们脱离具体的形象进行创新活动。  ---百度百科

    一:我们可以围绕业务组件我们的团队,对于某一快业务,我们可以指定一个对当前业务很熟悉的担当模块组长,进行开发。

    二:关注产品而非项目,对于我们一直做项目的人来说,产品项目有时候傻傻分不清楚。因为对于项目而言,我的开发周期,是在一个项目上线的点将项目完成,并且验收成果,就可以资源释放。这样人员的成长是很小的,但是微服务就不同,微服务倡导的是采取产品的模式惊喜团队组建,这样一个段杜复杂整个服务的生命周期,是从分析,开发,测试,并且运维来完成整个开发周期的。

    三:技术多样性,这个对于开发人员而言,是一个很大的挑战,因为以前一个项目可能只有Java,或者C#等高级面向对象的语言一种,但是微服务就不同,它会更具不同的业务,自己进行开发语言选择。

    微服务不是银弹

    我已经说了很多微服务的好处,但是微服务不是银弹,我们要考虑实施微服务的时候要考虑以下问题:

    1.分布式系统的复杂度

    2.运维成本

    3.自动化部署

    4.服务之间依赖测试

    5.服务之间依赖管理

    6.分布式事务管理

    最近很偷懒,本来这个想了好长时间,但是一直没写。想想还是写了。并且在下次写的时候会把XCD项目中对于上面提及的问题,会说明我和我的小伙伴是怎么做的。

    以上的内容有一些事参考于网上进行了整理。并且说明了一下个人意见。

    相关文章

      网友评论

        本文标题:鲜驰达项目之第三次重构--微服务之微服务架构阐述

        本文链接:https://www.haomeiwen.com/subject/zgvrrttx.html