微服务架构风格,即六个特点: 一组小的服务, 独立的进程, 轻量级的通信, 基于业务能力, 独立部署, 无集中式管理
微服务架构是架构风格,微服务架构六个特点是,一组小的服务,独立的进程,轻量级的通信,基于业务能力,独立部署,无集中式管理. 传统服务是集中式服务,微服务第一点是一组小的服务,不是代码行数个数的多少,而是集中的单一职责原则的服务,不论是业务还是技术上的单一职责; 独立的进程,什么是进程,比如启动word,比如启动迅雷,一个软件的启动和使用过程就是一个进程,比如可以运行jar包,可以运行在tomcat上等等,都是独立的进程; 比如使用Web Service中的soap通信等重量级的通信协议,而微服务则主张使用轻量级的通信协议,比如现在的http,json数据格式传输,彼此之间不耦合; 微服务是基于业务进行划分的,比如用户服务,登录服务,订单服务,支付服务等等,是基于业务能力去构建微服务内容; 独立部署,不同的业务团队,负责维护自己的模块内容,进行自己的维护和迭代,不需要进行团队的协作,对业务支持能力会等到显著的增强; 无集中式部署,比如不需要独立的架构团队进行处理,每个团队根据自己的业务需要选择不同的技术栈内容.
服务之间松散的耦合,不可以进行强依赖,比如如果a团队开发某个业务,必须依赖于b团队,那么就不能称为松散耦合; 服务之间面向的架构,本质还是SOA的理念,只是更细化,去进行落地而已;有界上下文,也称之为局部状态,每个团队可以维护自己的数据源,那么不同的团队可以进行不同的演化数据的发展,对业务的支持会得到增强,没有集中式的数据库的管理.
问题:微服务对业务的发展有什么好处呢?如果有独立的数据源,那么会有什么挑战呢? 彼此没有相互影响,便于快速开发,业务响应能力得到增强,迭代速度加快.如果是独立的数据源,那么会造成事务的一致性难以处理.
[大白话理解:如果你的公司业务有很多模块,比如用户模块,订单模块,产品模块,支付模块,优惠券模块等等,那么首先基于业务能力进行模块划分,模块完成后,单独成为项目,那么就需要独立部署,如果独立部署,那么一定都是单独的进程去运行代码;单独运行,服务之间的通信呢,就要使用轻量级的通信协议,然后就是非集中式管理,每个团队有自己的编程语言,架构风格,独立的数据库,模块之间不存在相互影响.最后就是业务的单一职责原则,微服务就是小的服务,小不体现在代码量上,体现在技术和业务的单一职责原则]
