没有最好的架构,只有最适合的
优势:
- 独立性
- 敏捷性
- 技术栈灵活
- 高效团队 {微服务团队规模比较小,每个团队只负责自己的微服务、技术上的调整、架构上的变化、只需要几个人开个小会就可以决定下来。}
不足:
- 额外的工作 {服务的拆分}
- 数据一致性 {单体架构只有一个数据库,通过事务单表、多表CRUD很容易达到数据的一致性,而微服务它们都有自己的数据库,即使我们在拆分微服务的时候,也尽量的保证对数据库的链表操作}
- 沟通成本 微服务API改变
微服务架构带来的问题及解决方案
1.微服务间如何通讯?
-
thrift是一种rpc通讯协议,restful是http的一种规范,http是一种协议,http和thrift可以看做同一个层面的东西,
* 只是http应用广泛,被大家熟知,并且成为浏览器的标准了。
它们都可以实现远程调用。a.通讯模式/方式 b.通讯协议 RPC、RESTFUL API 服务之间的是一对一还是一对多的关系? 是同步的还是异步的? 在什么时候服务与服务间需要通讯,httpclient,如何高效、快捷通讯
2.微服务如何发现彼此?
zookeep或者eureka、consul
3.微服务怎么样部署?更新?扩容?4.如何选择RPC框架
a. I/O、线程调度模型
b.同步I/O还是非阻塞的异步I/O、NIO
c.短链接: 发一次请求得到响应,之后就把链接断开 如:http
d.长链接: 链接时间比较长,只要链接上了就尽量保持链接状态,而不会主动把它关掉。
e.线程调度模型: 它是单线程还是多线程,线程的调度的算法是怎么样的b. 序列化方式 a).可读的:xml,fastjson b).二进制:人工不可见的,jdk 自带的 为什么要考虑序列化方式? 因为序列化方式它的效率直接影响RPC通讯的效率
5.微服务是一种架构风格
没有强制性、没有绝对标准的答案,是一种个建议而已,细节上了,可能有许多不同的理解。
微服务特点:
1.一系列微小的服务共同组成
2.运行在自己的进程里
3.每个服务为独立的业务开发
4.独立部署
5.分布式的管理
6.轻量级通讯方式6.分布式定义
皆在支持应用程序和服务的开发,可以利用物理架构由 多个自治的处理元素,不共享主内存,但通过网络发送消息合作。在分布式系统中,服务注册中心是最重要的基础部分
7.适合上微服务吗?
1.业务形态不适合的
.系统中包含很多很多强事务场景的
.业务相对稳定,迭代周期长
.访问压力不大,可用性要求不高
8.康威定律
任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。
服务拆分的方法论
9.如何拆分"功能"
1.单一职责、松耦合(修改服务,另外一个服务不用跟着修改)、高内聚
2.关注点分离
1.按职责
2.按通用性
3.按粒度级别
10.服务和数据的关系
1.应该先考虑业务功能,再考虑业务功能对应的数据
2.无状态服务(如果一个数据需要被多个服务共享才能完成一个请求,那么这个数据就称为无状态)