什么是微服务?(一)

转载自:https://www.oschina.net/news/70121/microservice

前言

最近听到了有同学在面试过程中遇到了关于微服务的问题,所以今天就转了这样的一篇很有意思的博客,作为对于微服务的了解~,因为篇幅很长,所以分为两篇

微服务简介

这次参加JavaOne2015最大的困难就是听Microservice相关的session,无论内容多么水,只要题目带microservice,必定报不上名,可见Microservice有多火。最喜欢其中一页。关于这个典故,可以参考this,此图适用于一切高大上的名字——技术有SOA,Agile,CLOUD,DevOps等等,古代有道,气,八卦等等。此类名词的最大特点就是 一解释就懂,一问就不知,一讨论就打架。

什么是微服务?(一)_第1张图片

微服务的流行,Martin功不可没,这老头也是个奇人,特别擅长抽象归纳和制造概念,我觉的这就是最牛逼的markting啊,感觉这也是目前国人欠缺的能力。

Martin Fowler是国际著名的OO专家,敏捷开发方法的创始人之一,现为ThoughtWorks公司的首席科学家.福勒(Martin Fowler),在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面,都是世界顶级的专家,现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和集成的公司。早在20世纪80年代,Fowler就是使用对象技术构建多层企业应用的倡导者,他著有几本经典书籍: 《企业应用架构模式》、《UML精粹》和《重构》等。—— 百度百科

先来看看传统的web开发方式,通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的,这种方式一般被称为Monolithic(比较难传神的翻译)。所有的功能打包在一个 WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI等所有逻辑。

什么是微服务?(一)_第2张图片

Monolithic比较适合小项目,优点是:

  • 开发简单直接,集中式管理

  • 基本不会重复开发

  • 功能都在本地,没有分布式的管理开销和调用开销

它的缺点也非常明显,特别对于互联网公司来说(不一一列举了):

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断

  • 代码维护难:代码功能耦合在一起,新人不知道何从下手

  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长

  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

所以,现在主流的设计一般会采用Microservice Architecture,就是基于微服务的架构。简单来说, 微服务的目的是有效的拆分应用,实现敏捷开发和部署 。

什么是微服务?(一)_第3张图片

用《The art of scalability》一书里提到的scale cube比较容易理解如何拆分。你看,我们叫分库分表,别人总结成了scale cube,这就是抽象的能力啊,把复杂的东西用最简单的概念解释和总结。X轴代表运行多个负载均衡器之后运行的实例,Y轴代表将应用进一步分解为微服务 (分库),数据量大时,还可以用Z轴将服务按数据分区(分表)

什么是微服务?(一)_第4张图片

微服务的具体特征

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.
– James Lewis and Martin Fowler

把Martin老头的定义大概的翻译一下就是下面几条,这个定义还是太抽象是不是,那就对了,就是要务虚,都说明白了谁还找他付费咨询啊,这么贵。

  1. 一些列的独立的服务共同组成系统
  2. 单独部署,跑在自己的进程里
  3. 每个服务为独立的业务开发
  4. 分布式的管理

Martin自己也说了,每个人对微服务都可以有自己的理解,不过大概的标准还是有一些的。

  • 分布式服务组成的系统
  • 按照业务而不是技术来划分组织
    - 做有生命的产品而不是项目
  • Smart endpoints and dumb pipes(我的理解是强服务个体和弱通信)
  • 自动化运维(DevOps)
  • 容错
  • 快速演化

未完待续。。。

你可能感兴趣的:(♥,随便玩玩)