没有最好的架构，只有最适合的
优势：
- 独立性
- 敏捷性
- 技术栈灵活
- 高效团队 {微服务团队规模比较小，每个团队只负责自己的微服务、技术上的调整、架构上的变化、只需要几个人开个小会就可以决定下来。}
不足：
- 额外的工作 {服务的拆分}
- 数据一致性 {单体架构只有一个数据库，通过事务单表、多表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.无状态服务(如果一个数据需要被多个服务共享才能完成一个请求，那么这个数据就称为无状态)