解析微服务架构(三):微服务重构应用及IBM解决方案

解析微服务架构系列文章将分几篇描述微服务的定义、特点、应用场景、企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架构转型。

上一篇文章介绍了融入微服务的企业集成架构的演进,并介绍交互式系统的微服务模式及技术决策例子。

本篇文章将介绍已有IT应用如何进行微服务重构的转型,以及IBM微服务相关解决方案的介绍。

微服务转型

采用微服务架构意味着以更复杂的运维环境为代价,实现更高速的应用交付及更快推出市场。因此企业需要在更快的交付与更复杂的运维之间进行权衡。

大部分企业都有大量遗留的应用系统,因此对需要更快更好地满足业务需求成为迫切任务时,大部分情况下企业不会全新构建一个完整的应用,通常情况下是企业对已有应用进行重构或希望能尽量重用已有代码

向微服务架构演进通常包括以下几个阶段:

1.传统的SOA服务化改造;

2. 开始引入某些微服务原则,进行针对性重构,如“一个任务一个服务”;

3. 引入整套完整的微服务原则;

4. 实现微服务的规模化 – 添加服务发现、服务缩放能力等增强特性。

并非所有应用都需要完成上述的各个阶段,一个基本原则是重构解决针对性业务问题,需要避免为了“微服务”而“微服务”化。

需要注意的是并非所有应用都可以转变为微服务架构:

  • 部分系统无法重构为微服务架构:例如非常老旧又缺乏维护的系统,对此类系统可以采用“如果应用无法被打破,就不要试图解决它”的策略,其中SOA资产重用化应该是更佳的解决方案。
  • 原有应用无法改变数据存储方式:对这种情况,需要考虑如果数据仍然保持烟囱式或集中式存储,那对应用进行微服务化是否具有业务价值;需要考虑切分数据库是否会导致事务性保障的缺失并进而影响系统的稳定性;同时也可以考虑应用能否采用如BASE、CQRS等模式解决数据的一致性问题。
  • 原有系统如何融入微服务架构:在原有系统中剥离部分功能并重构为微服务时,如何实现微服务与原有系统在高可用性上的隔离,如果原有系统与微服务的扩展性不匹配又如何处理?这些问题也许要在进行微服务重构前考虑清楚。

微服务重构

重构应用方面,可通过以下方法梳理微服务:(1)每个REST服务是一个潜在的微服务;(2)每个SOAP web服务或EJB是一个潜在的微服务,特别是无状态的session bean,需要将面向功能的接口重新设计为面向资产的接口,并使接口转变为RESTful形式;(3)使用领域驱动设计(domain-driven design)发现企业资产,这些资产可能是微服务。

重构数据方面,需要考虑以下几个方面:(1)寻找与其他数据关联不大的数据孤岛,检查系统的实体-关系图;如果有与其他数据断开的数据,就是一个潜在的数据重构点;(2)数据表非规范化,对高规范化数据库中非规范化一些数据表以将数据重组为更大的逻辑块,其目的是增加数据冗余度使其更容易被打破;(3)反向批数据更新,对数据重构时需要考虑数据重构失败时可批量地将新数据反向导回旧的数据模式;(4)使用主数据管理,对被广泛使用的数据实体组成一个单一的一致性视图,并开发相应的微服务与主数据一起工作;(5)在SQL数据库中寻找存储在BLOB(二进制大对象)字段类型中的代码,转而将这些对象存储在NoSQL数据库中,例如以键值(Key-value)存储方式存储;(6)寻找活跃的记录模式,与其他无关的Flat对象,使用文档模式数据库进行存储,例如Cloudant或Mongo等。

微服务重构后还需要重新打包应用,包括:(1)分割应用的EAR文件并打包成独立的WAR文件;(2)应用“一个容器一个服务”,分别部署每个WAR文件至其自有的WebSphereLiberty实例运行时或Docker容器中;(3)分别构建、部署和管理,为每个WAR文件使用独立的DevOps管线,每个WAR文件独立伸缩和管理。

微服务IBM解决方案

  • API Connect - 创建、运行、管理及保护API能力开放和微服务应用的企业级平台。

企业为了加速应用开发以满足不断增长的需求,需要开放内部的业务和数据能力并吸引合作伙伴及开发者基于其能力快速创新,IBM API Connect为企业提供了一个统一完整的API能力开放平台解决方案,实现API的创建、运行、管理、安全保证和微服务运行环境以满足企业参与API经济的需求。

IBM API Connect平台为数字化应用提供基础能力:(1)创建微服务并将为其提供对外的API接口;(2)管理、控制及保护REST和SOAP API;(3)为企业内外的应用开发者提供自服务的API门户;(4)将API接口发布到多个开发者门户;(4)分析API用量和性能指标。

  • WAS Liberty+WXS - 基于OSGi内核,高模块化,高动态性的轻量级WebSphere应用服务器,以及具备企业级高可用性的缓存服务,助力快速交付的微服务应用

微服务应用要求与各微服务有独立的运行环境,因此传统的应用服务器容器显得过于笨重,因此企业需要使用轻量级的应用服务器容器,但同时还需要考虑完善的技术服务支持。

IBM WAS Liberty是IBM开发的基于Java的轻量级WebSphere应用服务器,既满足了创新型应用轻量级的要求,又为企业提供了有效的商业技术支持,避免企业由于使用开源软件而有可能出现的技术支持风险。

WXS(WebSphere eXtreme Scale)则提供高性能、可扩展的高速缓存框架和网格技术,通过多样化数据存储加速微服务应用访问效率。

  • PureApp+ICO+UCD组成的混合云框架为企业提供私有云自动化部署的完整解决方案

微服务应用需要IT基础设施提供多种自动化能力以实现应用的快速上线和自动伸缩。IBM UrbanCode Deploy、IBM CloudOrchestrator和IBM PureApplication是三种可供企业客户组合搭配提供包括企业自动化部署加速应用持续交付、企业私有云自动化弹性伸缩环境和软硬一体化的私有云解决方案

  • IBM Bluemix 创新应用开发平台

微服务架构提倡使用多样化的编程语言多样化的存储,以最适合的技术解决业务需求并实现快速上线自动伸缩。IBM Bluemix平台能够很好地满足此类需求。

Bluemix 是一个基于开放标准和云的平台,可以用于应用的快速构建、运行及管理。Bluemix 由三大关键的开放计算技术支撑:Cloud Foundry, Docker, 以及 OpenStack。在其上进行了大量服务(目前超过100多种,并且服务数量还在不断增长)的扩展,健壮的 DevOps 工具,集成能力,以及无缝的开发人员体验。

Bluemix四大核心能力提升创新应用交付速度和价值:(1)Bluemix提供一体化运行环境,保证创新应用秒级上线;(2) Bluemix提供百余种流行的服务模块,构建应用简单快速;(3) Bluemix提供高效管理手段DevOps,保证应用强健稳定;(4) Bluemix可以放在本地,又可以无缝连接其公有云,具有多种部署模式,让企业具有更大的灵活性,形成更大的创新生态圈

——本文转载

时间: 2024-08-06 08:48:38

解析微服务架构(三):微服务重构应用及IBM解决方案的相关文章

升级微服务架构2:服务注册

微服务架构中,服务是最小的可伸缩的独立部署的单位,同一个服务提供可以有多个实例,这些实例都会注册到服务注册中心(Eureka Server)上进行统一的管理及调用的负载均衡. 因Spring Cloud的是已Java为主要开发语言,本文会先讲Java语言的服务怎么注册到服务中心,然后按照这个逻辑移植到.net版本上. 1.创建java版服务,并注册到服务中心 1.1创建一个Eureka Client的Maven项目 操作模式和上一篇使用Maven创建Eureka Server一样,模块名:use

面向服务架构~本地轮训服务占用内存过高的问题

对于WEB程序来说,它寄宿在IIS提供的w3wp进程中,这个进程占用的内存大小和你的应用程序的使用有个直接关系,你的程序写的标准,它占用内存就相对低,你的程序写的伪范规,该释放的东西不让系统释放(有些对象GC回收不了),就会造成内存使用过高的情况,对于32位系统来说,最高1.6G,超过后,进程自动挂掉! 对于本地服务来说,一般我们采用windowService,windowform来承载,它会自己有一个进程,而最近,我的windowService占用内存过高的问题真的出现了,不到5分钟,进程已经

微服务架构下的服务发现

编者的话]这是关于使用微服务架构创建应用系列的第四篇文章.第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点.第二和第三篇描述了微服务架构内部的通讯机制.这篇文章中,我们将会探讨服务发现相关问题. 为什么要使用服务发现? 我们设想一下当正在写代码时,使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口).传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的.例如,代码可以从一个经常变更的配置文件中读取网络位

微服务架构 - 解决Docker-Compose服务编排启动顺序问题

基于Docker Compose进行服务编排时,一定碰到服务启动顺序的问题,例如:B服务启动之前,A服务要已经启动并且可以正常对外服务. 这个启动顺序的问题,Docker Compose本身它是无法解决的,即使定义了depends_on或者links,它只能保证该服务依赖这些服务,启动本服务时会将依赖的服务也启动,但是启动顺序无法得到保证. 目前本人实验比较好的方案有两种: 基于wait-for-it.sh实现,前提条件是本镜像要支持bash 对于自己构建的镜像时,让工程本身带一个监听类,用于监

springcloud Spring Boot mybatis分布式微服务云架构(三):服务提供与调用

上一篇文章我们介绍了eureka服务注册中心的搭建,这篇文章介绍一下如何使用eureka服务注册中心,搭建一个简单的服务端注册服务,客户端去调用服务使用的案例. 案例中有三个角色:服务注册中心.服务提供者.服务消费者,其中服务注册中心就是我们上一篇的eureka单机版启动既可,流程是首先启动注册中心,服务提供者生产服务并注册到服务中心中,消费者从服务中心中获取服务并执行. 服务提供 我们假设服务提供者有一个hello方法,可以根据传入的参数,提供输出"hello xxx,this is firs

spring cloud微服务架构 服务提供者和服务消费者

服务提供者和服务消费者 下面这张表格,简单描述了服务提供者/消费者是什么: | 名词 | 概念 | | ----- | ----------------------- | | 服务提供者 | 服务的被调用方(即:为其他服务提供服务的服务) | | 服务消费者 | 服务的调用方(即:依赖其他服务的服务) | 服务提供者代码示例 这是一个稍微有点复杂的程序.我们使用spring-data-jpa操作h2数据库,同时将该服务注册到注册中心Eureka中. 1.创建一个Maven工程,并在pom.xml

(九)整合spring cloud云服务架构 - commonservice-config配置服务搭建

1. 介绍 Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持.使用Config Server,您可以在所有环境中管理应用程序的外部属性.客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同,因此它们与Spring应用程序非常契合,但可以与任何以任何语言运行的应用程序一起使用.随着应用程序通过从开发人员到测试和生产的部署流程,您可以管理这些环境之间的配置,并确定应用程序具有迁移时需要运行的一切.服务器存储后端的默

Spring Cloud云服务架构 - commonservice-config配置服务搭建

1. 介绍 Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持.使用Config Server,您可以在所有环境中管理应用程序的外部属性.客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同,因此它们与Spring应用程序非常契合,但可以与任何以任何语言运行的应用程序一起使用.随着应用程序通过从开发人员到测试和生产的部署流程,您可以管理这些环境之间的配置,并确定应用程序具有迁移时需要运行的一切.服务器存储后端的默

“灾难无情人有情”:备战金三银四之微服务架构问题!(含解析)

前言: 现在IT界跳槽已成常态,跳槽,可能有以下原因: 技术达到瓶颈,无法在此公司有好的提升,前几年我感觉基本不会出现,至少我现在没出现. 实力与薪资不匹配. 和同事 领导不和,如果你在几家公司都这样,要自我检讨一下是不是自己的问题. 仅个人观点,其他诸如地域 情感 兴趣等个人原因不做讨论. 这也导致很多企业在用人时会比较在意员工的稳定性一般外包公司都会比较忙,相对来说,成长应该是比较快的,而你的工作性质偏业务,那么你要想清楚一个问题,以后你的发展轨迹是怎样的?是在技术方向越走越远呢,还是在管理