一、服务架构的演变
- 单机模式：所有服务，如mysql、redis、项目文件等都部署在同一台机器上面。这样产生的问题就是项目抗压能力会受到机器的限制，当访问量大时会导致整体崩盘。
- 集群模式：针对的是 程序部署 方面，俗称砸机器。就是将同一程序部署在多台服务器上面，通过负载均衡，比如nginx，减轻单台服务器的访问压力
- 分布式：针对的也是 程序部署 方面，只不过是不同的机器部署不同的程序。比如讲MySQL、Redis、PHP程序分别部署在不同的服务器上面
- 微服务：针对的是 软件功能 方面。就是将软件项目根据功能的不同拆分成不同的模块，比如将商城系统，拆分成商品模块、订单模块、支付模块、后台管理模块等等。需要注意的是，这里并没有强调机器，也就是说，微服务注重的是功能的拆分，从概念上来说，即便将这些模块放在同一台机器上，也能称之为微服务。当然，真正项目中肯定不会放在同一台机器上
其实在实际项目当中，集群、分布式、微服务都是一起运用的。比如reids和MySQL会采用集群，不同的服务也采用集群，部署到不同机器上。从整体架构看，又用到了分布式和微服务
二、微服务的核心要素
- 拆分
1.1 从系统纬度层面拆分，比如商品模块、用户模块、订单模块等等。
1.2 从功能纬度拆分，比如订单模块又可以分为购物车、支付等不同功能
1.3 从读写纬度拆分，比如商品模块，读的概率要远大于写的概率，所以可以把读写分开
1.4 从模块纬度拆分，比如后端的controller、service、model，可以将model拆开，因为数据量大了后会进行分库分表，相应的model层面的数据聚合也会变得更复杂
1.5 从AOP纬度拆分，将整个项目都会用到的模块，比如日志、权限、系统配置等拆分 - 服务化
2.1 服务化与组件的对比：组件可以应用在尽可能多的系统里，而服务更换不同系统会因为出现业务冲突而无法运行，比如将商城系统的权限管理挪到erp系统中，会出现问题
2.2 服务化与子系统对比：这两者都是独立部署运行，区别是子系统脱离了整体系统依旧可以运行，而服务虽然是独立运行，但是却依赖于整体项目业务流程而存活 - 无状态
无状态指的是单独服务中尽量不要存储一些状态信息，比如权限认证服务，所有涉及到要验证用户信息的地方都要访问下该服务，这样产生的问题就是如果该服务挂了，其他的服务都会连带着出问题。
解决方案就是将这些信息存储在分布式缓冲中，比如说redis，所有服务都从redis集群中获取信息 - 消息通信
服务之间的通信方式一般会用到消息队列和rpc通信，对外会用restful接口为主
rpc是服务与服务之间调度的简称，特点是及时性高，消耗大消息队列特点是延迟性高，消耗小
rpc的实现方式其实就是借助于客户端，当两个服务要通信时，一个服务将自身转换为客户端，向另一个服务发送信息，然后接收的服务处理完业务后又会将自己转换成客户端向之前请求自己的服务发送返回信息
