微服务架构-模块迁移

标签: IT咨询 | 发表时间:2016-06-28 16:24 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难。对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出。下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤。

在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据。对于招投标模块我们将模型简化来看,主要涉及到上游,下游和底层共享数据几个方面的集成,初步分析如下:

1. 上游需要集成项目管理系统中项目信息,招投标基于已经立项的项目信息。
2. 下游需要集成当前遗留的采购系统,其中招投标结果信息和认证合格的供应商信息需要同步到采购模块。
3. 底层业务需要调用供应商,企业组织,人员等基础数据信息。
4. 底层技术需要调用流程引擎能力,实现招投标模块内部的流程建模和执行监控。

有了以上内容后可以看到,对于上述接口都需要进行服务化,不管是招投标模块本身提供的服务还是其需要调用和消费的服务。在该过程中就存在一个现实问题,其它已有业务系统是否会配合进行服务化的改造?如果其它系统很难配合,那么在微服务模块的迁移过程中就存在要单独实现一个服务代理模块,由该模块来实现接口的服务化工作,该服务代理模块本身还可以实现统一服务目录库的工作。在企业整个微服务架构逐步成型后可以看到该服务代理模块能力会最终融入到微服务网关和总线上。

其次,在服务实现上需要考虑的一个关键问题就是我们通过服务调用消费的数据尽量不落地,即实时的通过服务同步查询外围共享数据,包括项目信息,供应商,人员等基础信息。而在招投标内部的表中也仅仅存储外键ID,减少对重复数据的冗余。而对于我们需要分发的数据则尽量是通过消息中间件机制实现异步分发,减少耦合。由于数据不落地会导致我们在招投标模块前端实现过程中存在多次数据查询后组合,这是不可避免的问题。当然你也可以在招投标模块中增加一个领域服务层来实现类似组合服务的功能。

这些都考虑清楚后需要考虑私有数据库的设计,注意在微服务模块剥离过程中,招投标模块本身需要对应一个独立的私有数据库,可以是SID数据库实例级别,也可以是Schema级别。当采用Schema级别的时候务必注意不能使用跨Schema的关联数据库表查询语句,否则在数据库层面仍然是紧耦合。在数据库剥离后可以看到,对于招投标模块本身内部业务功能到私有数据库可以采用内部API方式进行调用,但是对于外部的数据和业务协同只能通过发布的服务进行调用和集成。

底层虽然进行了微服务和模块化改造,但是用户最终关心的仍然是完整的业务系统和功能,因此在微服务模块剥离后需要考虑的就是整体外层门户框架的单点集成能力。对于单点集成方案已经有很多标准的实现方式,在此不再进行详细描述。

在任何一个微服务模块的改造过程中,仍然涉及到底层平台层能力如何解决的问题?拿上面的场景来说,原有的采购管理系统里面可能已有有完整的流程引擎能力,那么剥离的招投标模块是否采用该流程引擎?还是说在微服务模块的改造过程中将核心的平台层能力也逐步剥离出来,如将流程引擎能力也剥离出来形成独立的共享流程平台。这些都是我们需要考虑的问题。个人建议的方式仍然是伴随着微服务模块的迁出同时,将可共享的核心平台层能力也同步剥离,形成底层共享技术服务能力平台。

一个微服务模块没有和Docker集成并不代表不是一个完整的微服务架构,一个微服务架构的核心判断标准仍然是组件化和服务化,数据库的单独剥离。上述的这些问题考虑清楚后,接着才考虑该微服务模块内部的技术架构和服务实现方式等问题。在单个微服务模块的实现中仍然推荐采用类似OSGI总线来实现内部的集成,在该模式下组件本身的动态部署和扩展能力将刚强。也更加容易在后期将内部的API发布为外部可以消费的服务。对于前期对开源ESB的研究可以看到,类似Karaf这种基于OSGI的框架可以是一个备选方案。

微服务模块在迁出地过程中应该尽量减少对已有业务系统的影响,减少对用户使用层面的影响。即任何业务系统架构改造和内部的复杂性都应该屏蔽在内部。这是在整个架构迁移过程中的关键原则之一。

在上述整体思路清晰后,剩余的即是关键技术问题的解决,包括了分布式事务,接口安全和性能,动态部署,弹性扩展,模块健康监控,DevOps能力等,这些在整个实施过程中都必须逐个考虑和解决。要清楚一个遗留的系统在进行微服务架构改造中,前期是增加了复杂度,特别是前期的解耦和后期的集成。微服务架构改造真正受益的是在后期的运维管控和平台弹性扩展上。

 

相关 [微服务 架构 模块] 推荐:

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

[服务器架构]微服务的深入思考

- - CSDN博客推荐文章
微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能. 举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: . 计算新的库存该存到什么地方. 计算在仓库内将库存运往正确放置点的路线. 计算仓库内指定一组订单的拣货路线. 以上这些功能(可能还会有更多)都是由单个微服务实现的.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.