微服务知识
传统开发所有业务逻辑都在一个应用中, 开发,测试,部署随着需求增加会不断为单个项目增加不同业务模块;前端展现也不局限于html视图模板的形式,后端向前端支持需要更多的接口模块。
随着需求增多,项目变大,单体系统部署在一个进程内部,往往修改很小的功能,为了部署上线也会影响其他功能。后期维护成本会变得越来越大,难以控制。
微服务架构中不同模块拆分成不同服务,都能独立部署和扩展,运行在自己的进程内,有稳定的边界,更新也不会影响其他服务运营。而且由于是独立部署的,可以更准确的为每个服务评估性能容量,也更容易发现系统瓶颈位置。
微服务带来的问题
微服务架构有如此多优点,单也因为服务的拆分引入了许多问题。
微服务实施
服务调用
在微服务架构中通常通过两种方式互相通信:
去中心化管理
在实施微服务架构时,希望每一个服务都管理其自由的数据库,这就是数据管理的去中心化。
但随之而来数据一致性也成了需要解决的问题直以,分布式事务本身实现难度就非常大,所以在微服务架构中,强调在各个服务之间进行无事务的调用,对数据一致性,只要求数据在最后处理状态一致即刻;若在过程中发现错误, 通过补偿机制来进行处理,使得错误数据能够达到最终的 一 致性。
以下内容摘自我的领域驱动设计(DDD:Domain-Driven Design)笔记
传统架构,数据一般是强一致性的,我们通常会使用数据库事务保证一次操作的所有数据修改都在一个数据库事务里,从而保证了数据的强一致性。在分布式的场景,我们也同样希望数据的强一致性,就是使用分布式事务。但是众所周知,分布式事务的难度、成本是非常高的,而且采用分布式事务的系统的吞吐量都会比较低,系统的可用性也会比较低。所以,很多时候,我们也会放弃数据的强一致性,而采用最终一致性;
CQRS(Command Query Responsibility Segregation)架构 - 命令查询的责任分离, 则完全秉持最终一致性的理念。这种架构基于一个很重要的假设,就是用户看到的数据总是旧的。比如秒杀的场景,当你下单前,也许界面上你看到的商品数量是有的,但是当你下单的时候,系统提示商品卖完了。
容错设计
单体应用中, 一般不存在单个组件故障而其他部件还能运行的情况,通常是一挂全挂。
在微服务架构中,当部分服务存在故障,而导致没有返回,线程挂起等待,直到超时才能释放。正常服务频繁调用故障服务,导致大量线程被挂起,从而出现故障蔓延。
所以晶块检测出故障源并京可能自动恢复服务很关键。通常希望每个服务中实现监控和日志记录,比如服务状态,断路器状态,吞吐量,网络延迟等关键数据的仪表盘。
思想转变
设计服务时,需要学习领域驱动设计,细致的分出每个服务和相关边界。
实施微服务的团队,每个小组都应该以做产品的方式,对服务的整个生命周期负责。
Spring Cloud 介绍
Spring Cloud 是基于Spring Boot的微服务架构开发工具,它为微服务中涉及的配置管理,服务治理, 断路器, 智能路由, 微代理, 控制总线, 全局锁,决策竞选,分布式会话和集群状态管理等操作提供了简单的开发方式。
常用子项目:
更多的技术分享,尽在我的公众号:Java小朔哥
还有我把近一年经历过的面试,和一些刷过的面试题都做成了PDF,PDF都是可以免费分享给大家的,只要关注我的wx公众号:java小朔哥,就可以获取免费领取方式!