大家可能手头都维护着一定数量旧系统，系统可能还能跑，但是跑的怎么样，可能没有人能说清楚，还时常需要维护：重启、应对安全检查啥的，它代码可以追溯到张山、李四到王二麻子好多代秃顶的码农。面对着这样的窘境，你能做的，而且唯一需要做的就是对其重构，重新开发一个全新架构的，高性能的，流行的系统。本文中虫虫给大家介绍实例Java平台重构的方法，将Java Spring开发的系统迁移到ReactJS+API的 微服务架构 。
基础梳理
为什么要重构平台架构？
主要原因如下：
如果不引入滞后，风险甚至更复杂的代码（库），则无法发布更新（新需求）。
希望性能更好，界面漂亮的系统，还能改善用户体验，但是不知道从哪着手。
必须要升级开发工具栈，采用更新的技术或要解决过时的问题。
目前的架构
在开始重构架构之前，我们必须了解系统的当前状态。结合本文，一个典型的Spring架构如下图：
很有可能在这个平台上工作了很长时间，并且出于第一部分所述的各种原因，你必须的做架构重构。但是缺乏测试资源，还还不想破坏任何东西，你不知道如何做？那么你请随着虫虫继续往下走。
重构目标
首先，我们必须明确目标：拥有一个完成以下任务的架构。
移动化 ：可以处理移动应用程序并轻松将其连接到我们的业务逻辑。
可维护 ：可以在不引入错误或导致任何问题的情况下对业务逻辑进行更改。所有更改都能反映在所有平台（网络，移动，第三方接口）上。
自动化 ：可以轻松编写自动化测试，集成CI服务器，并为CD环境铺平道路。
清理 ：清理HTML和CSS。我们将拥有结构良好，语义和可维护的UI。
面向 微服务 的架构可以轻松实现所有这些目标。但同时，我们又不能破坏日常业务运营，我们不能只是从头开始重写。我们需要一个现实的过程，这意味着假设当前代码的很大一部分仍将驱动你的业务逻辑。我们必须一步一步，朝着一个明确的目标迭代。
架构大迁移
基础准备
首先，我们介绍一些背景。我们不需要重新造轮子， 又很多 成熟现有架构可以使用。
ReactJS的强大之处在于它是一个库，而不是一个框架。这使我们可以实现模块化，一次迁移一个组件，直到最终实现前端UI和API的完全分离，为实现现代架构奠定基础。
我们需要做的第一件事是确定应用程序的自包含组件。这是一个新功能，无论是简单还是作为痛点。我们都可以使用ReactJS编写这个新组件。接下来的部分：当UI在服务器中呈现并作为HTTP响应发送时，我们如何将新的ReactJS组件集成到现有平台中去，我们一般使用两种方法：
渲染页面
如果我们创建的组件是一个完整页面，则可以使用自己的URL创建一个全新的ReactJS站点，并将其与Spring UI分开。为了实现功能站点的分离，我们需要一个 反向代理 ，可以使用Nginx作为代理服务器来重构架构：
反向代理调度
我们可以通过Node.js运行新ReactJS站点，或者只是静态页面，比如存在云对象存储的静态图片等。我们需要一个URL模式来决定特定页面是从Spring还是从ReactJS调用。在示例中，我们使用”/ui/*”，因此遵循模式”站点/ui/*”的所有内容都将反向代理到ReactJS：
我们最终目标是将所有内容移至ReactJS并替代掉Spring框架UI层。
渲染特定组件
在某些情况下，渲染整页的方法行不通。由于页面太复杂，我们想仅仅先仅迁移特定页面的特定组件开始。
在Spring框架生成的UI中包含 占位符 。
假设我们想要使用ReactJS呈现客户端列表。然后我们必须包含一个占位符div（或部分或表）。比如：
包含一个Javascript文件，该文件将查找所有ReactJS占位符并为每个占位符运行渲染器。我们可以使用props传递信息，但理想情况下，每个组件都应该从后端获取所有数据。
链接API
通过渲染一个ReactJS组件，作为整页或现有组件中的较小组件。现在我们必须将它与API连接起来。可以使用最拿手的语言创建API。如果有Java团队情况下使用Java，Golang也是一个非常好的选择，甚至是Python或者 Ruby 等。我们创建一个RESTful JSON API，该API可以使用我们现有代码的服务层。从头开始构建所有内容通常是不切实际的，我们有很多业务逻辑，重写基本上没有任何可能。因此，我们要利用已有代码来创建我们的API，这样架构转变为：
迭代开发，逐渐剥离旧代码
当完成前端判断组件，使用ReactJS编写组件以及为此构建前端站点的过程中，可能会发生一些事情，但是这些都未必是麻烦，反而能帮我们理清业务逻辑和旧的系统。
如果确定正在构建一个全新的模块，我们就可以创建一个新的API。这是微服务方法的一个步骤。随着不断迭代扩展，这些新API可以使用其他语言或技术栈构建，连接到不同类型的数据模块（如 NoSQL 缓存数据库，数据中间件等）。
这个过程中，必须为每个API撰写足够详细的文档（API管理可以使用Apiary），并在必要时复用现有业务逻辑（服务层）。
作为附加功能，也能增加对移动APP的支持，它们连接到相同的API。我们可以使用ReactNative并重用一些现有的ReactJS组件。迭代后的系统架构图如下：
淘汰弃用旧的Spring框架表示层
通过上一步的迭代开发，我们的系统逐渐实现用ReactJS构建的100%的Web应用程序，并一步步减少对Spring表示层的依赖性。
通过Restful服务公开了所有数据，例如，该图包含使用不同语言（Golang）和NoSQL数据库（Redis）构建的新API。
根据需要，任何API都可以访问 DBMS ，也可以不访问DBMS。不同的ReactJS组件将使用不同的端点和不同的API。
整个架构最后呈现方式如下：
本文中虫虫给大家介绍了架构迁移方法和实例，帮助实现从Java Sping架构到ReactJS+API的微服务架构，实现业务解耦和架构优化升级，并且带来了对移动APP支持等额外的功能等。
