互联网转型需要微服务架构

微服务出现的时间不短了,但是为什么现在才这么重视它?互联网转型要转型什么?

第一,以职能为中心转向以用户为中心。我们过去的信息化更多的是依照部门职能,有什么样的工作内容,有什么样的流程,然后去做系统。下一步的信息化更多的是以用户为中心。为什么是以用户为中心?我们要看用户到底需要什么,在什么样的场景下需要什么样的信息支持。过去我们只在内部做很多系统,其实用户体验也非常的不好,用户需要的东西也没有。

第二,从流程驱动转向数据驱动。过去都是看业务流程是什么样的,流程中间需要什么样的数据来支持。随着移动互联网、物联网这些数据的产生,根据数据的分析判断或者驱动新的流程,所以新的应用场景是由数据来驱动的。

第三,从事后录单转向现场数据自动采集。过去的信息化都是靠人工输入,发生的业务就输入一些信息进去。今后由于移动互联网和物联网实时数据的采集,我们做好实时的在现场的采集,反而不需要人工做采集、手工录入。

第四,从封闭系统转向开放系统。过去的系统都是封闭式的,开发它的时候没有考虑到开放、没有考虑到互联或者被谁调用。今后的系统开发出来,应该是微服务的方式,它是暴露API,某个系统不需要知道被谁调用、被调用多少次,该系统在开发时就做到是一个开放的系统,暴露API。

第五,从单机架构转向分布式架构。总体来讲,过去的信息化都是基于单机的架构,俗称叫IOE架构,在单机上做的整个基础设施,包括上面的应用、数据库都是基于IOE结构写的,下一步要转向分布式。分布式是从基础设施一直到应用都要做到分布式。为什么要转向分布式?是因为要做到弹性可扩展,满足大量的并发、交互和大的用户量和数据量。

第六,从中心化治理转向去中心化自治。过去的信息化走到今天,到SOA这样一个阶段大家知道仍是中心化治理的阶段,依靠总线来做交互、路由;下一步在微服务的模式下是事件的驱动,服务之间他们如何去被调用、如何去走流程是通过事件驱动的,而不是中心化的思路做治理,更多的是去中心化的自治。

举例:美国GE说,GE未来是一个软件企业,为什么?因为所有一切是被软件所定义,背后是云平台、大数据平台的支撑。GE打造的工业互联网平台:前端通过连接所有的设备、资产,端到端所有跨业务流程的,包括合作伙伴、客户所有这些东西都通过云平台的连接,设备产生的数据、产品的数据都基于云方式存储。在云上,有了数据,数据驱动各种创新的应用,通过融合分析可以得出很多的洞察,包括设备的可预测性维护等等。这个工业互联网平台底层就是PaaS和IaaS,上面就是微服务的架构。整个应用架构是朝微服务的方式转型,不管是对资产的,就是设备、装备还有各种分析的服务、数据存储服务、安全服务、运营服务都是基于这样一个平台在打造下一代微服务的架构、微服务的应用。数据架构方面从融合的大数据架构转型。通过物联感知,各种各样的数据在产生,这些数据通过数据的管道结构化,这些结构化的数据怎么存储、非结构的数据怎么存储,对于需要实时处理的数据怎么存储计算,对于一些不需要实时处理的数据怎么存储,这里面会进入到一个融合的大数据的架构基础上去做数据的存储和计算。有了数据的基础上我们再做一些分析和利用,支持或是引导业务变革和创新。

  从以上互联网转型我们就可以看到为什么需要微服务的架构:

第一,快速的创新。在互联网时代我们需要快速的创新。不像过去,我们做一个系统花了很长时间,半年甚至一年实施出来,为时晚矣。信息时代,我们需要快速的响应和交付。

第二,随时随地的服务需要随时的连接。

第三,网络的规模。也就是说我们的服务,我们可能随时要被大量的人访问、数据随时大量的产生,这样一种大量数据的产生、大量用户访问的规模也需要有一种新的弹性架构支撑它。

第四,以移动为中心的用户体验。所有这些导致我们要基于微服务架构构建一种原生的云应用。所谓原生的云应用,就是在互联网的基础平台上基于微服务架构开发的应用,它是弹性可扩展的,可以支持大并发大交互。

总之,未来业务的敏捷一定要依赖于IT的敏捷,我们一直追求敏捷的IT:一个弹性可扩展的云计算与大数据基础平台(IaaS + PaaS),加上基于微服务架构的原生云应用(SaaS)开发,这已成为企业级IT的必然选择!

北达软信息化咨询与培训中心(国家信息资源管理北京研究基地)是一家专注于EA研究、咨询和培训的服务机构。成立于2006年,注册在北京大学科技园,通过了ISO9001质量体系认证。北达软最早将TOGAF、FEA、ESA和Archimate等企业架构认证培训引入中国。通过将EA与云计算、大数据、物联网和移动互联网等新IT技术的结合,北达软已形成一套完善的新IT架构或互联网架构设计与转型方法论。

本文转自d1net(转载)

时间: 2025-01-23 14:56:31

互联网转型需要微服务架构的相关文章

InfoQ采访PWorld2015讲师:解读“微服务”架构

经历过去的十几年的发展,SOA(Service-Oriented Architecture)已经获得了广泛肯定与应用.现在,随着云计算.开源.Docker等为技术界带来革命性的影响,同时,用户使用方式与生活方式都在移动化浪潮的裹挟下发生了巨变,"微服务"架构(MSA:Micro Service Architecture)这一全新的企业架构模式越来越受到关注,也有越来越多的企业和平台服务商开始将"微服务"的概念转化为实践,掌握到第一手的实战经验.应该如何理解"

谈微服务架构(转)

时间 2016-03-22 11:38:33  人月神话的BLOG   原文  http://blog.sina.com.cn/s/blog_493a84550102w5x6.html 主题 微服务 其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,

12年互联网产品开发人眼中的微服务架构云端应用

微服务架构很热,讨论的文章非常多.但如果提到微服务架构的云端应用,可以深入分析的还比较少.本篇来自中生代技术群(FreshmanTechnology)第二期,好雨云创始人兼CEO刘凡的分享.其曾任澳客网 CTO和CEO职位.拥有超过12年互联网产品开发和管理经验,专注于互联网技术架构设计,对产品设计.敏捷开发.安全.OKRs.大数据等领域有深入研究.现推崇反应式编程(http://www.reactivemanifesto.org/),并在多个产品中成功应用. 下为正文: 微服务架构(Micro

如何拆分你的微服务架构?

如今,市场环境纷繁复杂,瞬息万变,现代企业为了更好地生存,需要有极强的适应能力.快速而轻松地迎接改变,成为了一个优质企业的特征之一,同时企业还要求技术团队构建更科学的架构,搭建成本更低的平台,这就使得这些团队越来越倾向于使用微服务架构来应对以上要求. 微服务的做法有利于软件组件和数据的分散化,将一个整体分解成更小.更容易改变的部分,分散仅帮助团队加快工程进度,而不会牺牲系统的安全性.要想让这种架构工作得很好,需要改变工作方式. 微服务架构的设计,其实是为了使团队能够在执行工作的人之间分配决策权力

你了解微服务架构么?

摘要:微服务架构最主要的两个特征:细粒度和独立,简单来讲微服务就是细粒度的独立的服务.这有什么好处呢? 微服务架构最主要的两个特征:细粒度和独立,简单来讲微服务就是细粒度的独立的服务.这有什么好处呢? 第一,细粒度就是每一个服务专注做好一件事情,每个服务完成一个单一任务.在功能不变的情况下,应用被分解为多个可管理的服务,很好的解决了复杂性问题. 第二,独立开发,独立测试,独立部署,独立更新.开发者不再需要协调其它服务部署对本服务的影响.这种改变可以加快部署速度,快速的部署变化.因为是分布式的,微

微服务架构的理论基础 - 康威定律

概述 关于微服务的介绍,可以参考微服务那点事. 微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 .前段时间看了Mike Amundsen <远距离条件下的康威定律--分布式世界中实现团队构建>(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容. 可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且

学霸君基于Docker的微服务架构设计

以下内容根据演讲PPT以及现场分享整理而成. 今天主要分享的是我们在实践微服务架构或者容器架构过程中踩过的坑,对于致力在容器技术方面进行探索的同学会有很大帮助.本次将站在整体的角度,分享如何去运维整个线上系统,如何看待整个微服务的架构.微服务能带来什么帮助以及微服务又有哪些缺点,还有重要的一点就是微服务架构如何去落地实施.虽然阿里云这样的服务商为我们做了大量的工作,但是将微服务架构真正地落地实施还需要做很多的工作.而对于任何技术而言,都是存在优缺点的,微服务架构也不是救世的良药. 一.学霸君的发

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段

图解微服务架构演进

图解服务化架构演进 前言 来自dubbo的用户手册中的一句话:随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进. 常规的垂直应用架构就相当于传统的那种,现阶段传统垂直架构改造的核心就是对应用做服务化改造,服务话改造使用的核心技术架构就是分布式服务框架. 其实这篇是概念上的总结,技术概念软文,纪录此文让自己更明白什么是微服务化架构. 服务化架构演进 那什么是微服务架构呢? 先从第一个图中第一个说起