微服务架构的优势和不足

没有最好的架构，只有最适合的

优势：

独立性
敏捷性
技术栈灵活
高效团队 {微服务团队规模比较小，每个团队只负责自己的微服务、技术上的调整、架构上的变化、只需要几个人开个小会就可以决定下来。}

不足：

额外的工作 {服务的拆分}
数据一致性 {单体架构只有一个数据库，通过事务单表、多表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.无状态服务(如果一个数据需要被多个服务共享才能完成一个请求，那么这个数据就称为无状态)