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

https://mp.weixin.qq.com/s/IWR_wIh2D-RmPuslR_JnXg

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

2017-04-12 胡平 甲骨文开发者社区

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

谈及微服务架构,就不得不提及传统单体应用(monolithic)架构,如下图所示:

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

  1. 单体应用的部署物(范围)一般是某个完整的业务应用场景,比如网银、社保或更大的像ERP等。
  2. 采取中心化的数据存储方式,虽然可以实现集群或数据分区,单数据存储始终是集中式的。
  3. 采用单一的技术框架或优化方式,例如整个单体应用都是采用统一的语言编写,例如Java, .Net等,所有的优化,包括CPU、内存、IO、网络资源都是基于单体应用完整实例进行。
  4. 扩展无论是垂直还是水平扩展的单位,也都是单体应用本身。
  5. 从开发运维模式来讲,基本都是开发和运营独立,人员组织机构基本上按照UI, 应用逻辑和数据的应用三层技术架构进行划分。

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

1.  太复杂:

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

2.  交付太慢:

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

3.  太脆弱:

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

4.  缺乏优化:

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

5.  代码没有归属者:

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

6.  无效率测试:

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

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

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

  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. 安全性:必须认证和授权每个单独的主体,单体应用典型的都是自己来认证和授权,每一个单独的远程网络调用都要进行安全保护,可以利用网络分段来隔离各个微服务。

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

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

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

  • Java云服务:基于J2EE的微服务应用可以直接部署在Java云中
  • 应用容器云服务:底层基于Docker的应用服务器云服务可以为微服务应用支持更多平台语言的选择,例如J2SE,Node.JS等

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

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

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

  • Oracle API Catalog:简化API的收集、注释和发布,易于应用开发者实现API的发现、消费、评价和评分
  • Oracle API Manager:API开发门户,发现和测试API,注册使用它们的应用程序,在运行时监控使用情况。
  • Oracle API Gateway:API安全网关,提供部署在本地或云端的应用访问的接入安全,提供数据格式转换和协议桥接。

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

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

时间: 2024-10-06 03:44:21

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

(转)微服务架构 互联网保险O2O平台微服务架构设计

http://www.cnblogs.com/Leo_wl/p/5049722.html 微服务架构 互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小

微服务架构(一):什么是微服务

解析微服务架构系列文章将分几篇描述微服务的定义.特点.应用场景.企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架构转型. 为什么需要微服务架构 "微服务"架构是近期软件应用领域非常热门的概念.让我们先来看看传统IT架构面临的一些问题: 使用传统的整体式架构(Monolithic Architecture)应用开发系统,如CRM.ERP等大型应用,随着新需求的不断增加,企业更新和修复大型整体式应用变得越来越困难: 随着移动互联网的发展,企业

微服务架构案例(04):中间件集成,公共服务封装

本文源码:GitHub·点这里 || GitEE·点这里 更新进度(共6节): 01:项目技术选型简介,架构图解说明 02:业务架构设计,系统分层管理 03:数据库选型,业务数据设计规划 04:中间件集成,公共服务管理 一.中间件简介 中间件是基础软件的一类, 属于复用性极高的软件.处于操作系统软件与应用程序的之间.是一种独立的系统软件,也可以是公共的服务程序,分布式架构系统借助中间件,可以在不同的技术之间共享资源,或者不同的服务直接传递信息.中间件位操作系统之上,管理计算机资源和网络通讯.是连

Re:从0开始的微服务架构--(二)快速快速体验微服务架构?--转

原文地址:https://mp.weixin.qq.com/s/QO1QDQWnjHZp8EvGDrxZvw 这是专题的第二篇文章,看看如何搭建一个简单模式的微服务架构. 记得好久之前看到一个大牛说过:如果单体架构都搞不好,就别搞微服务架构.乍一看,这句很有道理,后来发现这句话是不太对的,因为微服务架构的目的就是为了降低系统的复杂性,所以 微服务架构应该比单体架构更简单.更好实践才对. 这篇文章,我们就分享一下如何搭建一个 简单模式 的微服务架构. 什么是微服务架构的简单模式? 相对于大型互联网

【微服务架构】SpringCloud之Eureka(服务注册和服务发现基础篇)(二)

上篇文章讲解了SpringCloud组件和概念介绍,接下来讲解一下SpringCloud组件相关组件使用.原理和每个组件的作用的,它主要提供的模块包括:服务发现(Eureka),断路器(Hystrix),智能路有(Zuul),客户端负载均衡(Ribbon),Archaius,Turbine等  今天学习的是Eureka即注册中心 一:Eureka简介 Eureka是Spring Cloud Netflix的一个子模块,也是核心模块之一.用于云端服务发现,一个基于REST的服务,用于定位服务,以实

微服务架构中整合网关、权限服务

前言:之前的文章有讲过微服务的权限系列和网关实现,都是孤立存在,本文将整合后端服务与网关.权限系统.安全权限部分的实现还讲解了基于前置验证的方式实现,但是由于与业务联系比较紧密,没有具体的示例.业务权限与业务联系非常密切,本次的整合项目将会把这部分的操作权限校验实现基于具体的业务服务. 1. 前文回顾与整合设计 在认证鉴权与API权限控制在微服务架构中的设计与实现系列文章中,讲解了在微服务架构中Auth系统的授权认证和鉴权.在微服务网关中,讲解了基于netflix-zuul组件实现的微服务网关.

Spring Cloud构建微服务架构(六)高可用服务注册中心

在Spring Cloud系列文章的开始,我们就介绍了服务注册与发现,其中,主要演示了如何构建和启动服务注册中心Eureka Server,以及如何将服务注册到Eureka Server中,但是在之前的示例中,这个服务注册中心是单点的,显然这并不适合应用于线上生产环境,那么下面在前文的基础上,我们来看看该如何构建高可用的Eureka Server集群. 单点Eureka Server的样例: GitHub 开源中国 Eureka Server的高可用 Eureka Server除了单点运行之外,

微服务架构的优势与不足-1(转)

「Chris Richardson 微服务系列」微服务架构的优势与不足 Posted on 2016年5月4日 编者的话|本文来自 Nginx 官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战. 转自http://blog.daocloud.io/microservices-1/ 作者介绍:Chris Richardson,是世界著名的软件大师,经典技术著作<POJOS IN ACTION>一书的作者,也是 cloudfoundry.com 最初

.Net 微服务架构技术栈的那些事

一.前言 大家一直都在谈论微服务架构,园子里面也有很多关于微服务的文章,前几天也有一些园子的朋友问我微服务架构的一些技术,我这里就整理了微服务架构的技术栈路线图,这里就分享出来和大家一起探讨学习,同时让新手对微服务相关技术有一个更深入的了解. 二.技术栈 2.1 工欲善其事,必先利其器 现在互联网盛行的年代,互联网产品也层出不穷,受欢迎的互联网产品都有一个比较牛的技术团队,我这里分享下.net 微服务架构技术栈图如下: 俗话说得好:工欲善其事,必先利其器.一个优秀的工程师应该善于使用框架和工具,