微服务

软件架构入门

软件架构(software architecture)就是软件的基本结构。

合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位(architect),只有资深程序员才可以担任。

O’Reilly 出版过一本免费的小册子《Software Architecture Patterns》PDF), 介绍了五种最常见的软件架构,是非常好的入门读物。我读后受益匪浅,下面就是我的笔记。…

微服务(Microservice)那点事

WHAT – 什么是微服务

微服务简介

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

微服务的流行,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等所有逻辑。
screenshot

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

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

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

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
  • 代码维护难:代码功能耦合在一起,新人不知道何从下手
  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

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

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

REST真的完全适合微服务架构吗?

【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。

在我接触微服务的这段时间,大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此,你可能理所当然地认为REST就是微服务的一种标准,并且是设计与实现微服务系统一种方式。然而,并非如此。…