一:什么是微服务?
微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。 系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。 每个微服务仅关注于完成一件任务并很好地完成该任务。 在所有情况下,每个任务代表着一个小的业务能力。
当然啦,关于微服务还有很多种定义,并没有一个官方的标准,通常在解释微服务的时候,通常会提起一种面向服务的架构——SOA,其核心的原则就是将应用组织成一独立的功能单元,可远程访问并单独进行操作和更新,简单来说,就是每个单元都是一个独立的服务,它可以实现业务的一个方面,并通过接口提供功能,虽然SOA清楚地指出服务应当是独立的进程,但是并未强制使用哪种协议进行交互,对于部署和配置还是相当模糊的,SOA服务可以在同一个机器上使用socket通过IPC(进程间通信)方式进行交互,若要使用内存共享,间接消息队列或远程过程调用(RPC),这是一个非常广泛的定义,只要没用在单个进程中运行所有应用,SOA可以是任何东西。
二:传统的单体架构
举例来说:一个商城,除了要有静态的HTML内容外,还必须要有相关的模块,比如用户模块,订单模块,商品模块,优惠券模块等等,当用户对应用进行操作的时候,会伴随着针对数据库的一些SQL操作,然后再经过渲染返回给HTML的页面,整过过程都相当于在一个应用的整体内进行,较少的对外部服务进行网络请求(比如注册时需要请求第三方短信验证),在经典的LAMP架构中,每个传入的请求都会在数据库生成关联的SQL查询,然后服务器再使用模板引擎生成相应的HTML进行响应。
这种架构有很明显的优缺点,优点就是:1.我们可以很容易的开始一个项目;2.简化了数据的设计和组织;3.部署应用也会相对简单
但他也有很明显的缺点:1.我们如果想增加一些功能的时候,修改代码可能会影响到原来不相关的功能,对某部分代码的错误修改可能导致整个应用的崩溃
2.扩展应用的解决方案存在的限制:可部署多个实例,但若期中一个特定的功能占用了所有资源,则会影响整个应用
3.随着应用的迭代,代码库的增长,很难保证代码的干净和可控性。
三.微服务架构
如下图所示:
如上图所示,这些微服务,诸如电子邮件的外部服务,将提供和单体应用相同的功能集,这个架构中的每个 组件都使用HTTP协议进行通信,拖过REST风格的web接口提供服务,每个微服务都在内部处理自己的数据结构,不需要中心化数据库,使用普遍的数据格式如JSON输入输出数据,任何语言都可生成和使用,最后通过HTTP请求和响应进行传输。总体来说,微服务是一个轻量级的应用,它可以通过良好的契约提供一组有限的功能,它是具有单一责任的组件,可独立开发和部署。
微服务架构的优点:
1.分离开发团队的注重点,每个微服务都可由一个团队独立开发,每一次版本迭代只会在服务的内部进行,不会影响其他的应用,低耦合的开发模式,加快项目的进程。
2.如果在现成的微服务应用中进行跨越式的迭代,比如说更换语言和框架,我们可以把它隔离在一个微服务中,使用独立的数据库,让一小部分用户去试验这个方案,从而不影响整个应用的运行
3.更加灵活的扩展与部署,根据微服务的定义,我们可以将服务部署在不同性能的服务器上面,需要消耗CPU的放在性能优良的服务器上面,只消耗内存的(如Redis这种内存数据库)我们可以部署在CPU稍微较差,而内存较大的服务器上,从而减少了部署的成本
有好肯定有坏:
1.微服务若出现不合理的拆分,当你重构一些业务逻辑时,你的代码就会让你搔首踟蹰了,嘻嘻,如果你要实现一些功能,总是要部署两个微服务,或者你改变了一个微服务总会影响另一个数据模型时,你就该考虑合并两个微服务了
2.在微服务的构建过程中,使用了很多的网络交互,这也带来了问题,如有由于网络隔离或服务延迟,“商城HTML”无法及时调用相关的服务,这会产生严重的后果
3.假如用户添加的系统中来,进行某些数据操作时,是不是需要同步每一个服务,这样做会不会产生冗余呢,保持微服务的隔离的同时又要尽量避免数据的重复
4.兼容性的问题,可能会出现版本的不一致
5.测试上的问题,众所周知,产品要部署上线时肯定要经过相应的测试,但是微服务架构是一个分离的架构,不同于单体架构,他需要相应的工具才能进行测试,这也是限制微服务开发的一个难题。