什么是微服务——微服务在现有框架中的应用转化及重构

各位小伙伴们大家好，上一章解释了一下什么是微服务，这一章主要是介绍微服务如何融入企业框架，并对其进行重构，下一篇文章估计会写一下我们用的轻量级微服务框架都用到了什么，以及如何搭建，行了，先看这一章吧。

企业微服务架构的引入主要集中在以下两类系统：

记录型系统：是指传统的应用系统，对应用所关注领域的信息进行增删改查作为应用的核心能力。如CRM、ERP、OA等系统。记录型系统使用的往往是一些传统的经典IT技术构建，往往更难改变，其集成难度也较高。

交互型系统：是指以与用户交互为主要目的而开发的应用系统。如各种移动应用、微信、微博等等。交互型系统更多地会采用现代的各种新技术语言及运行时部署，具体高度的敏捷性，通过简单的现代化连接即可实现集成。

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

不同的企业背景应该采用不同的微服务架构引入策略：

对大型的成熟企业而言，由于本身已有大量在建的企业IT系统，因此决定了微服务架构仅是其多种应用架构风格之一，大型企业在服务总线与能力开放网关的集成架构下，可以首先从交互型系统入手引入基于微服务架构的应用，逐步积累面向微服务的开发运维经验。另外，对于部分新建的记录型系统，也可以考虑采用微服务架构进行构建，并通过服务总线等SOA集成技术实现与企业遗留系统的信息交互。

二、对于初创企业而言，由于其没有任何历史包袱，因此可以考虑将企业范围的整体架构以(微)服务架构为基础进行搭建。

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

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文件独立伸缩和管理。