微服务架构概述

微服务相信大家都不会陌生,我们到处都可以看到这样的名词,那微服务是什么呢,解决了什么样的问题

这是一个电影操作系统的服务,我们把整个系统分成了电影模块,订单模块和用户模块,最终我们把它打包成一个war包,

部署到TOMCAT里面去,这种架构风格,我们称之为单体架构,我相信一开始大部分的项目,都是以这种架构方式进行架构的,

而且项目初期的话,这个项目会跑的很好的,但是随着业务的发展,整个项目越来越复杂,模块越来越多,这个时候我们可能

就会面临着各种各样的问题

它是一个单体项目,他大致也分了一些模块,这些模块的边界非常的模糊,同时代码的质量不是很好,

业务和需求的变更,也是比较的频繁,这个导致了项目的复杂性非常的高,第二个技术债务逐渐上升,

这种思想在单体架构里是非常严重的,我们知道人员它是流动的,可能会有人离职,而这个人员往往会埋坑,

每个人员他的水平也不一样,随着人员的进进出出,因为你埋的坑没人解决,第三个部署速度逐渐变慢,因为随着

业务的发展,各个模块可能会越来越多,而且模块的代码也会越来越多,那他的启动当然也会越来越慢,我之前的

项目启动可能要15分钟,非常的恐怖,第四个是阻碍创新,阻碍技术创新,这指的是这样的,因为技术是在不断地发展,

而我们这个项目呢,假设他是5年之前创立的一个项目,他一开始用的是Struts,而我们现在往往喜欢用SpringMVC了,

假设我们要进行修改,更换,这其实是非常困难的,首先我又大量代码需要重新写,各种各样的UI啦,都得改,第二个他的

风险也非常高,那怎么办呢,往往继续使用Struts呢,这其实是不利于技术的发展的,最后是无法按需伸缩,假设电影模块是

CPU密集型的服务,而定的模块是IO密集型的服务,订单模块发生的场景,更好的内存,更好的硬盘,但是我们应用是放在

一起打包的,那我们是不是要考虑他的CPU是不是不能太差,这个时候我们就要做一些妥协,这是单体架构存在的缺点,

那我们怎么样去解决这个缺点呢,那现在有一定规模的项目,我们知道架构是为了解决问题的

单点架构存在这样的问题,所以我们要想办法去解决这样的问题,现在又出现了微服务,关于微服务的

缺点呢,我们可以看一下这篇博客

http://www.zhihu.com/question/37808426

下面我们来了解一下什么是微服务,业界没有一个非常明确的一个定义,我这里引入了Martin Fowler对于微服务的

一个描述,他说,简而言之,微服务架构风格这种开发方法,是以开发小型服务的方式,开发一个独立应用的,每个小型服务

都运行在自己的进程中

http://www.martinfowler.com/articles/microservices.html

我们看微服务大概具备几个条件

一系列独立运行的微服务共同构建起了整个系统,很显然,每个服务独立的开发,围绕业务功能进行构建,

第四个微服务之间通过一些轻量级的通信机制进行通信,通过REST API和RPC方式进行调用,我们可以对比一下

单体架构和微服务架构

共享DB,共享资源,而微服务建议的是,每个服务单独运行,因为他有可能有自己的数据库,订单服务是IO密集型的,

而数据库定义是关系型的,不可能使用Redis,他们可能通过调用机制去调用,第一是易于开发和维护

针对单个微服务来讲的话,因为他只关注某一项业务,订单微服务他只关注订单,相对来讲它是

比较小的,因为他关注的点非常的有限,他的业务难度也会小很多,这样启动比较快,因为他关注的点比较小,

所以war包也比较小,所以启动会比较快,像订单服务里面我们做了小小的改动,电影模块并没有改动,那我们这个时候

只要修改这个微服务就可以了,第四个是技术栈受限,像这个模块可能用的是JAVA写的,这个模块我们一开始也是用JAVA

写的,我们发现这个用JAVA并不是很适合,或者开发成本比较高,而且不方便,我们后来想使用Node,我们对他进行重构或者

怎么样,这种成本会比较小,因为关注点比较小,第五个是按需伸缩,这更好理解了,比如它是CPU的,CPU密集型的,只要采购

更好的CPU,DevOps,以前我们是一个war包,就可以了,现在我们需要维护多个微服务,微服务还要进行相互的协同,才能完整的

构建一个服务,那假设手动的进行构建,进行打包的话,压力可见而知,所以需要一些自动化的工具,辅助我们开发和运维

任何一个东西,他不是完美的,他具备优点的同时,也带来了相应的挑战,运维要求比较高,刚刚其实我们已经知道了,

他只要维护一个东西就OK了,他可能需要维护多个微服务,哪个服务出问题了,就会导致那一块应用不正常了,运维要求会

比较高,第二个是分布式的复杂性,任何一个分布式系统,大家都了解,不细讲了,接口调整成本比较高,像订单用户服务,

它会被电影微服务所调用,假设我们用户的模型发生了变化,甚至用户的业务发生了变化,那很多时候电影微服务要调用他,

电影微服务要调用用户微服务,那这时候,用户微服务就发生变化了,电影微服务也要跟着调,有很多产品避免不了,有很多产品也能

避免,最后一个是重复劳动,像我们在这种架构模式下的,往往会成立一个公共组件,这种方式的话可能会有一点难度,工作量是

重复的,如果我们都是用的JAVA技术的,一些Maven,去单独的写公共组件,写好了之后打成一个jar包,大家都引用这个依赖,因为

微服务是不绑定技术栈的

在我们设计表的时候,我们也有设计原则,这里我们也总结了一些比较简单的设计原则,第一个是单一职责原则,

这指的是,订单微服务关注的是单一的,他只关注订单,他的职责很单一,单例的原则,我们要打造一个高内聚,

低耦合的项目,所以每一个微服务他关注的,应该是单一的,第二个是服务治理原则,这个是这样的,举个例子,

他应该有自己的开发,运维,部署,可以把它当做一个项目去运作,第三个是轻量级的通信原则,轻量级有两个特性,

第一个通信的协议,他这个协议是跨平台,跨语言的,为什么要跨平台跨语言的,第四个接口明确原则,这个是这样的

我们知道这种架构模式的话,SOA用ESB,WEBService之类的,微服务同样也是,首先SpringCloud,这个是我们课程的一个

主要话题,第二个是dubbo,因为微服务它是一个分布式的系统,我们往往会有一些通用的模式,降低微服务的开发难度,

或者让微服务更加的可维护,这个时候我们可能需要用一些各种各样的组件,去进行配合