一、微服务简介
1.架构发展
单体架构
开发方面
业务越来越复杂,代码量越来越大,代码的可读性,可维护性和可扩展性降低
新人接手代码时间成倍增加,业务扩展代价越来越大
测试方面
随业务扩张,单体应用修改或增加业务可能影响其他业务,造成测试难度增加
并发方面
用户增多无法承受并发量过大
单体架构服务器集群
特点
Nginx分发高并发网络请求
缓存服务器缓解数据库读写压力
不足
依然单体架构,可读性和可维护性依然很差
海量数据数据库成为瓶颈,使用分布式数据库即分库分表解决
微服务和SOA的关系
对于微服务来说,它是SOA的一种实现,但是比SOA更加轻便、敏捷和简单
微服务架构
按照业务来划分微服务单元
可按业务划分的微服务单元独立部署,运行在独立的进程中
服务之间通过HTTP协议通讯
一般倾向于HTTP通信,更多时候使用RESTfulAPI
也可以通过轻量级 的消息总线来通信,例如 RabbitMQ 、Kafaka等
//数据格式一般为JSON 、XML,这两种数据格式与语言、平台、通信协议无关,服务各自可用不同编程语言编写
//用Protobuf序列化的数据更轻量 ,但可读性非常差,在通信协议和数据存储上十分受欢迎
数据库独立
服务与服务不需要提供数据库集成,而是提供API接口相互调用
数据库独立,单业务的数据少易于维护,数据库性能有明显优势,数据库的迁移也很方便。
每一个服务的数据库都不相同,可根据业务需求来选择//如 MongDB 、 Redis
自动化部署
Docker容器技术的推进,以及自动化部署工具(例如Jenkins)的出现,自动化部署变得越来越简单
服务集中化管理
SpringCloud采用Eureka来注册服务和发现服务
//Zookeeper、Consul也是服务集中化管理框架
分布式架构
能够处理海量的用户请求
熔断机制
防止了“雪崩效应”事件的发生
2.微服务架构的优势与不足
微服务优势
将复杂的问题简单化
将一个复杂的业务分解成若干小的业务,每个业务拆分成一个服务,将复杂的问题简单化
可读性增加
服务按照业务拆分,编码也是按照业务来拆分,代码的可读性增加
扩展性增加
随着业务的增加,可以根据业务再拆分服务,具有极强的横向扩展能力。
低耦合
服务与服务之间完全独立,无耦合
新人学习时间成本减少
新人加入团队,不需要了解所有的业务代码,只需要了解他所接管的服务的代码
测试和部署
只需要测试并部署被修改的服务
微服务的不足
微服务的复杂度
构建的复杂度远远超过单体系统,如果修改某一个服务 ,可能会对另外一个服务产生影响
分布式事务
同时满足“一致性”“可用性”和“分区容错”是一件不可能的事。
而单体服务是CA系统,微服务系统通常是一个AP系统//C:Consistency强一致性,A:可用性,P:分区容错性
业界给出的解决办法通常是两阶段提交
第一阶段:
service-account发起一个分布式事务交给事务协调器TC处理
事务协调器TC向所有参与的事务的节点发送处理事务操作的准备操作
所有的参与节点执行准备操作将 Undo和Redo信息写进日志,并向事务管理器返回准备操作是否成功
第二阶段:
事务管理器收集所有(account和goods)节点的准备操作是否成功,如果都成功,则通知所有的节点执行提交操作 ;如果有一个失败,则执行回滚操作
尽量少使用分布式事务
如果分布式事务涉及的节点很多,某一个节点的网络出现异常会导致整个事务处于阻塞状态,大大降低数据库的性能
如果使用两阶段提交仍然有数据不一致,则依靠日志运维人工处理
服务的划分不易
服务是可以被替换和更新的
//即服务和服务之间无耦合,任何一个服务都可以被替换
服务的部署复杂
部署微服务系统,需要开发人员或者运维人员对微服务系统有足够强的控制力
//Docker为容器技术,是微服务最佳部署的容器
//DevOps是一种部署手段或理念
3.微服务的设计原则
单体构架
业务很单一时,如果在单体构架够用的情况下,就应该用单体构架
集群化部署
随着业务的发展,用户量的增加,可以考虑将数据库读写分离、加缓存 、加复杂均衡服务器、将应用程序集群化部署等
微服务架构
更高要求时候使用,目前比较流行的微服务框 架有Spring社区的SpringCloud、Google公司的 Kubemetes 等
微服务内存不下降 微服务数据存储
转载本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章