微服务架构探讨及甲骨文中间件微服务技术解决方案

随着传统企业受到互联网+的冲击，越来越多的企业都在面临业务转型，如何更好地贴近客户以获取更高的客户满意度，如何在企业内部加速供给侧改革，实现更好的供需平衡都是企业在业务转型中需要思考的问题。企业业务转型，离不开底层IT架构的支撑，所以最近很多很火的技术理念不断被大家所谈及，包括微服务架构、DevOps开发运维模式、数据集装箱Docker技术等。甲骨文也是一家在技术和理念不断创新的公司，今天就其中的微服务架构主题展开，谈一下我们的看法及相关中间件产品支撑的解决方案。

谈及微服务架构，就不得不提及传统单体应用（monolithic）架构，如下图所示：

单体应用有以下几个特点：

1. 单体应用的部署物（范围）一般是某个完整的业务应用场景，比如网银、社保或更大的像ERP等。

2. 采取中心化的数据存储方式，虽然可以实现集群或数据分区，单数据存储始终是集中式的。

3. 采用单一的技术框架或优化方式，例如整个单体应用都是采用统一的语言编写，例如Java, .Net等，所有的优化，包括CPU、内存、IO、网络资源都是基于单体应用完整实例进行。

4. 扩展无论是垂直还是水平扩展的单位，也都是单体应用本身。

5. 从开发运维模式来讲，基本都是开发和运营独立，人员组织机构基本上按照UI, 应用逻辑和数据的应用三层技术架构进行划分。

传统的绝大部分应用都是采用单体应用架构来进行设计，但是随着时间的推移，它的局限性也逐渐显现，主要包括以下几点：

１.  太复杂：

随着时间的推移，应用会变得越来越大，对开发者而言很难理解，而且共享层 (ORM, 消息处理等) 需应对100%的用户场景

２.  交付太慢：

团队按照功能划分– UI、应用、中间件和数据库等. 由于相互交叉，永远需要等所有的事情都做完才能交付

３.  太脆弱：

一个bug 会很快毁掉整个应用，缺乏弹性

４.  缺乏优化：

应用的不同组件有不同的需求–更多CPU、更多内存和更快的网络等，单体应用无法就某个功能组件进行优化。

５.  代码没有归属者：

代码将成为“公地悲剧”的受害者– 因为代码没有归属者，出了问题你只能选择忽略它

６.  无效率测试：

每次你改动应用，你必须重新测试整个应用，很难支持连续交付的需求。

微服务架构的出现基本上是对现有复杂大型单体应用架构以业务为单元进行拆分，每个拆分的微服务应用都可以单独部署和测试，可以采用单独的技术架构，独立的数据存储，独立的开发运营团队支撑，快速以微服务应用为单位进行弹性扩展，降低各个业务单元之间的耦合关系。具体和单体应用的对比可详见下图：

         如果企业出现了下面５个迹象，则可以尝试采用微服务架构进行应用设计：

1. 一个应用需要100+ 开发者

2. 一个应用＞5M代码行

3. 以月或者季度为单位来发布应用到生产系统

4. 积压 > 1 季度的开发工作

5. > 20% 开发者的人事变动

从下图可以看出，通常来讲单体应用依然是更好的选择，对于简单和中等复杂程度的应用，无论是长期还是短期来看其成本开销都是好于微服务架构，对于非常复杂的应用, 微服务架构长期来看会有回报，但是需要经历很长时间来弥合前期的巨大投资。

通常客户会混淆SOA和微服务，因为他们之间有很多相似的地方，包括松耦合的架构，通过模块化来降低复杂度等相似思想。甲骨文认为SOA是一个通用的理念，而微服务是其中一种具体的实现方式。两者最大的区别在于实现方式，SOA更多的是基于ESB来实现服务编排，我们可以把它称之为“简单接入，智能管道”，而微服务更多的是强调去中心化，与之相对应的是“智能接入，简单管道”。更详细的对比详见下图：

接下来我们简单讲一下微服务的实现方式，从几个角度来看，一个是架构角度，一个是技术实现层面。架构方面由于每个微服务应用都有自己的数据存储（如下图所示），所以微服务导致架构向分布式计算迁移，这里就需要考虑几个问题，第一根据CAP原则，我们需要再一致性、分区容忍度及可用性之间寻求平衡，这会造成最终一致性问题，我们在设计架构的时候一定要能够提前评估。第二由于所有微服务间的数据交换都需要通过API层，或者消息的方式来实现通讯，而不是原来单体应用内线程调用，其通讯成本会变得很高，同步的调用方式并不是最佳选择，一般会采用异步的消息方式来进行。

技术层面的实现技术核心组件主要包括以下几方面：

1. 服务注册：管理每个微服务接入点的全生命周期，自我感知多租户，微服务的版本和环境信息。

2. API负载均衡器：匹配每个请求到最佳接入点，查询服务注册来决定最佳接入点，为每个HTTP请求寻找最佳接入点。

3. API网关：为每一种类型（Web和移动端等）的客户端构建XML或者JSON的响应，异步的调用N个微服务来构建所需的响应，处理安全以及对后台的隐藏负载均衡，应用有限的应用逻辑。

4. 安全性：必须认证和授权每个单独的主体，单体应用典型的都是自己来认证和授权，每一个单独的远程网络调用都要进行安全保护，可以利用网络分段来隔离各个微服务。

下图是典型的微服务的方案架构图：

甲骨文中间件作为应用部署的最佳平台，对微服务的支持也是不遗余力，下面我们从几个方面来看看相关产品的支持：

１.  云服务支持：云服务的弹性及可扩展性是构建微服务架构很好的平台

• Java云服务：基于J2EE的微服务应用可以直接部署在Java云中

• 应用容器云服务：底层基于Docker的应用服务器云服务可以为微服务应用支持更多平台语言的选择，例如J2SE，Node.JS等

２.  WebLogic多租户：WebLogic的多租户特性可以实现应用的高密度部署，在共享资源的情况下，可以实现很好的隔离，同时可以支持基于分区方式的灵活迁移。这些特性对微服务架构都是必要的，我们知道微服务应用相对于原来单体应用拆分后，对高密度部署的要求更高，WebLogic的多租户特性可以保证在相同业务SLA的水平下降低服务器端 Java 基础架构的总拥有成本（硬件服务器数量减少66%，维护所需的工时数减少 25%）。

３.  WebLogic的Docker支持：Docker作为轻量的容器化技术，区别于传统的虚机的方式，可以实现更快的部署、启停以及迁移，这对于微服务的实现确实是有帮助的。WebLogic作为J2EE应用部署的最佳服务器，也在12.1.3及12.2.1的版本中增加了对Docker的认证和支持，可以基于单机或者多机的模式下进行基于Docker容器化方式的应用部署，这对于微服务应用基于Docker的实现可以说是一个更好的选择方式。

４.  Oracle API管理：前面我们介绍过，微服务的技术组成里包括了对API管理的相关功能，我们这里也简单介绍下相对应的甲骨文的中间件产品：

• Oracle API Catalog：简化API的收集、注释和发布,易于应用开发者实现API的发现、消费、评价和评分

• Oracle API Manager：API开发门户，发现和测试API，注册使用它们的应用程序，在运行时监控使用情况。

• Oracle API Gateway：API安全网关，提供部署在本地或云端的应用访问的接入安全，提供数据格式转换和协议桥接。

下图是实现微服务甲骨文中间件运行时选件的汇总：

最后我们来总结一下，微服务架构并不是一个银弹，他不能解决所有问题，我们也看到，没有一种开发模式，无论是在技术还是管理领域，可以承诺在10年内，无论是生产效率、可靠性还是简化程度可以领先其他技术一个数量级，所以我们需要根据实际的应用业务需求结合未来的发展趋势，做相应的抉择，选择最适合自己的软件架构，下图是我们就微服务应用的收益和成本的对比，作为最后的总结。