微服务架构的优势
- 独立开发:所有微服务都可以根据各自的功能轻松开发,比如同一个商城中,有秒杀、用户、会员、订单等多个相对独立的功能自成的单独的微服务服务
- 独立部署:基于自身的服务,可以在任何应用程序中单独部署它们,比如商城中有秒杀,用户,会员,但出问题或者新增功能的只是会员服务,那我们就只针对会员服务进行升级即可,不像非微服架构,升级一个功能或者修复一个bug,会影响到整个系统
- 故障隔离:即使应用程序的一项服务失效或者不起作用无响应,系统仍可以继续运行
- 混合技术堆栈:可以使用不同的预言和技术来构建同一应用程序的不同服务,因为各自需求和开发人员的不同,可能在技术选型上也有一定的差别,所以不同且互不影响
- 粒度缩放:的那个组件可根据需要进行缩放,无需将所有组件缩放在一起
微服务架构的特点
- 解耦:系统内的服务很大程度上是分离的,因此,整个应用程序可以强送构建,更改和扩展
- 组件化:微服务可视为可以轻松更换和升级的独立组件
- 业务能力:微服务非常简单,专注于单一的功能,订单服务就只处理订单相关的程序,不会处理用户、会员等程序
- 自治:开发人员和团队可以批次独立工作,从而提高速度,比如负责订单服务的开发说在创建订单的时候需要拿到用户的昵称,那用户的昵称是存放在token或者session再或者其他缓存里面可以拿到的,那用户的数据在登录接口就需要加上这个昵称字段并存放起来提供给订单服务的开发来获取到,不需要订单服务的开发在用户服务中继续修改
- 持续交付:通过团建创建,测试和批准的系统自动化,允许频繁发布软件,这个主要是依赖上面的优势2
- 责任: 微服务不关注应用程序作为项目,相反,会将应用程序视为他们负责的产品
- 分散治理:重点是使用正确的工具来做正确的工作,这意味着没有标准化模式或任何技术模式 ,开发人员可以自由选择最有用的工具或者技术来解决他们的问题
- 敏捷开发:微服务支持敏捷开发,任何新功能都可以快速开发并再次丢弃,比如开发一个双十一秒杀系统,但双十一过了之后,就可以停掉
设计微服务的最佳实践
- 每个微服务都有单独的数据存储:举个例子,订单系统和用户系统连接的数据库肯定不能是同一个数据源
- 使代码保持类似的成熟度:这是相对的,当然如果能绝对也可以,但是不太可能,没有bug的程序是不存在滴,相对的意思是支付要想成功,订单也必须要支持,生成订单前要支付成功,这两者之间的代码必须是要很成熟的,否则支付或者订单进行不下去
- 为每个微服务单独构建:升级或者修复bug的时候,部署要不能影响其他服务,比如
- 部署到容器中:使用容器会方便服务的水平拓展和节省服务器资源,否则微服会占用大量资源,比如服务器的内存等等
- 将服务器视为无状态:每次请求的信息都在请求里面,服务器自身不保存任何信息
微服务架构运作所需组件
- 客户端:来自不同设备的不同用户发送请求
- 身份提供商:验证用户或客户身份并颁发安全令牌、token等信息
- API网关:统一接口出口和入口,处理客户端的所有请求
- 静态内容:容纳系统的所有内容
- 管理/监控:在节点上平衡服务并识别故障
- 服务发现:查找微服务之间通信路径的客户端
- 内容交付网络:代理服务器及其数据中心的分布式网络
- 远程服务:启用驻留在IT设备网络上的远程访问信息
- 自动化部署:提供一键式部署平台
微服务架构的优点
- 可以使用不同的技术
- 每个微服务都侧重于单一独立的功能
- 支持单个部署
- 允许经常发布软件
- 确保每项服务的安全性
- 多个服务是并行开发和部署的
微服务架构的缺点
- 增加故障排除难度
- 因为远程调用而增加延迟
- 增加了配置和其他操作的工作量,比如运维
- 难以保持功能安全
- 增加了跨域各种边界跟踪数据的难度
- 很难在服务之间进行编码