写在开头:任何架构都不能解决所有问题,没有完美的架构,只有最合适的架构
先放大招
微服务简介
微服务一定要区别于系统，服务是指一个或者一组相对较小且独立的功能单元，是在某一设计维度拆分的最小功能集。
微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
传统单系统弊端
在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。
主要有以下几个问题:
1. 复杂性逐渐变高
单一系统随着功能的不断增加,在模块之间没有明确区分的情况下,逻辑会越来越乱,查找问题以及交接也会越来越复杂
2. 阻碍技术更新
单一系统使用的某个技术框架如果需要更新,需要查找所有依赖的逻辑,付出的成本代价想当大,所以单系统项目基本会一直使用最初搭建的项目架构一点一点增加补丁,直到无法维护.
3.无法按需伸缩
所有系统所有模块都是同等地位,没办法按照某些接口 IO/CPU 密集型需求单独增加对应的机器,提升系统的整体性能
4.数据和业务无法有效拆分
在传统系统中,所有数据库都在一起,经常会出现单个业务操作多个数据库等操作,导致系统之间业务和数据难以有效拆分.
5. 无法快速迭代
由于所有业务代码都在一起,不管大小迭代都需要经过完整的系统测试,不能测试系统某一部分来保证系统功能正常.
微服务优缺点
随着互联网应用数据量、并发量、业务复杂度的增长,单一系统已经无法满足业务,逐渐产生了微服务思想.
微服务架构主要解决了以下问题:
1.便于开发,测试以及查找问题
每个模块就是一个服务,代码量明显减少,遇到问题比较容易找到定位和修改.修改单个模块只要保证本模块测试通过就可以保证整个系统正常.
2.便于服务按需弹性伸缩
随着业务发展和并发增加,每个模块都要部署很多服务,每个模块可以按照模块性能按需进行弹性伸缩
3.便于数据和业务的封装
单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
4.便于使用新技术以及业务技术升级
单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。
微服务会引入以下问题:
1.分布式事务处理
比如转账业务,传统业务会修改用户余额,新增用户账单以及其他操作,如果有其中一个失败就会全部按失败处理,但是如果采用微服务,用户余额和账单如果不在一个服务中处理,就会产生错误数据.
2.RPC服务超时或失败
服务调用者应有一些应对策略，比如重发
关键服务例如支付，要注意幂等性，因为重发会导致重复操作
3.并发锁
相当于单服务中的锁机制
微服务粒度
从拆分粒度可以分为:
粗粒度：一个服务层
所有的信息存储都在一个service里，那么一个地方出bug，就将影响整个业务
一个子业务(数据库)一个service
这个是目前适合大多数公司业务系统拆分的架构
一个service出问题也不会影响其他service，同时数据层也按照业务垂直拆分开了
服务架构见下图
一个数据表对应一个service
等各个数据表之间也解耦开了，不会相互影响了
一个接口对应一个service
多个服务操纵同一个数据表，使用同一片缓存，每个接口出问题，都不会影响其他接口。
微服务设计原则
单一职责原则
意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
服务自治原则
意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
轻量级通信原则
首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
接口明确原则
由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
