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

转载自：

https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/%E8%A7%A3%E6%9E%90%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84_%E4%B8%89_%E5%BE%AE%E6%9C%8D%E5%8A%A1%E9%87%8D%E6%9E%84%E5%BA%94%E7%94%A8%E5%8F%8AIBM%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88?lang=zh

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

dW_Vikki | 2016年4月27日 | Visits (12468) 

1

     解析微服务架构系列文章将分几篇描述微服务的定义、特点、应用场景、企业集成架构的演进以及微服务转型思路和技术决策考虑等内容，并以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可以放在本地，又可以无缝连接其公有云，具有多种部署模式，让企业具有更大的灵活性，形成更大的创新生态圈。

 

 

——本文转载自 IBM 云计算华南团队（微信号：IBMCloud_SC）