将Java EE单体应用打造成微服务

本文讲的是<b>将Java EE单体应用打造成微服务</b>【编者的话】如何将单体应用拆分成微服务相信是很多人共同的疑问，本文作者就技术和组织结构等方面为我们提供了一个思路，一起来看看吧~

<a href="http://dockerone.com/uploads/article/20160731/f93625a23b1eb27102c0ce9ae8f5009e.png" target="_blank"></a>

过去我们花了大量的时间论证这一类型的架构，而这些工作似乎是有意义的。我们希望能够按照各个组件自己的需求来进行扩展。如果我们需要处理更多的web请求那就向外扩展web层就好了。如果那些服务开始陷入瓶颈，那就扩展业务服务层。与数据库以及数据访问层打交道和管理维护对于整个应用/服务的其他部分而言是相对独立的。从中间层和数据访问中“解耦”出来UI逻辑是一个不错的指导原则，但是不要把它和必需的分层搞混淆了。

实践中的真实情况是所有这些“分层”的架构化组件，针对所有对它的单独关注来看很容易殒命于数据和数据库引发的怪问题。我们可以尽情地添加所需的CPU，中间件和UI，但是无论我们的网络、计算、内存等等变得如何快速，对于这类系统的瓶颈往往都在于域模型和最终的数据库的相互竞争。这里面的压力便是“域模型”———互联网公司所践行的微服务可能不会拥有像FSI或者保险、零售商那样复杂、模糊而又矛盾的域模型。比如，推特有一个简单的域：发布和展示推文。但是这一案例也会在大规模场景下变得复杂———一些企业正开始同时遭遇这两方面问题的困扰———域模型及其复杂性与如何扩展它同等重要（并且常常会

在努力扩展时有所妨碍）。所以如今你单纯想着“我们只要用一个像MongoDB这样的NoSQL数据库就能实现后端的扩展性”的话———你现在恐怕会遇到更多问题。

那说说我们的团队？像这样架构一个系统的另外一部分是因为这样我们就能在这些分层上分配各个专业的团队以不同的效率，在不同地方，用不同的工具等相对独立地进行工作。他们只需要和其他人共享一个接口，然后便能自主进行他们的工作。这里用到一点康威定律:

设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

让我们一起来看看到底发生了什么。以Ticket Monster为例，业务要求我们改变所处理网站的管理方式。他们要求我们添加一些相关的额外字段来追踪音乐会在网站上添加和删除的频繁程度，因为他们想据此添加一些预测分析，基于时间，位置，天气等决定在未来添加该活动是否是一个好主意。如果业务想要给管理用户展示这个预测分析的话，这可能还会涉及到UI团队。这也必将涉及改变应用的业务逻辑层，并且它肯定会导致数据库的变动。我们想给我们的应用添加一些功能特性，而这引发了所有分层的波动效应，而更为重要的是，涉及到了整个团队。如今我们不得不需要项目经理为所有相关团队协调和跟进会议。我们需要在创建票单的时候保证UI和团队做什么事情不会让QA，安全，运维等全部介入。所有这一切造就了我们各个团队之间的复杂同步处境，而如今我们不得不协调我们分层的全部变动，构建和发布（并且一切都同时部署！）。这不是我们想要的那种自治。我们无法相互独立地做出变动，事实上，我们已经变得相当脆弱。

针对我们的Ticket Monster应用，让我们改为将功能切分成可拼接的各个“垂直频道”而不是以技术或者组织层面。每一个垂直频道有它自己的“UI”（或者UI组件），“业务服务”和“数据库”，它们用于管理网站的特定功能。（然而，在第一步里，我们将把UI留作一个单体，然后将它背后的模块切分开来。我们会回过头来切分UI，尽管这有其自己的挑战。）Ticket Monster还允许用户查看和预订音乐会票。让我们将这块功能切分到它自己的垂直频道里。它可能也有忠诚度，推荐，搜索，广告，个性化等等。我们将这些都切分到它们自己的垂直频道里，每个都拥有它们自己的数据库，UI，和集成点（REST服务，后端，等等）。如果我们需要对网站忠诚度这块功能做出变动的话，我不需要去重新部署整个单体的业务服务层或是任何相关的服务，比如搜索。我可以从UI到DB部署忠诚度这块的功能而无需再被迫触发其他服务的变动。在理想情况下，一个团队拥有和运维的每个服务都将如此。

<a href="http://dockerone.com/uploads/article/20160731/06430b3f538dd7bd8bb1a1898b7b1fca.png" target="_blank"></a>

<b>原文发布时间为：</b>2016-07-31

<b>本文作者：</b>吴佳兴

<b>本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。</b>

<b></b>

<b>原文标题：</b><b>将Java EE单体应用打造成微服务</b>