微服务架构的优势和不足

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

优势：

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

不足：

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

​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​