一、微服务架构
在大型网站中，要面临的问题很多，但核心问题还是数据量、访问量快速膨胀带来的稳定性、性能、成本、效率的问题，此外就是和算法相关的问题。
一、微服务的演进
单体架构 -> 集群 -> 垂直化 -> SOA -> 微服务化
1. 单体架构
引入问题： 单机支持的并发量有限，且会存在单点故障，功能模块都放在一个进程内，没有进行资源隔离。
2. 集群
随着并发量提升，一台tomcat支持300并发量，部署集群2台理论上就可以支持600的并发，部署集群可以提升并发量，同时也避免了单点故障，提升了可用性。
其中请求的分发需要负载均衡算法，且服务是无状态化的；
存在问题：随着业务复杂度提升，服务耦合严重。
3. 垂直化
一个产品随着用户越来越多，业务复杂度也随之越来越高，因为产品要满足各年龄段、不同兴趣爱好、地域等不同人群的需求，这些人群的需求体验都不一样；此时将这些业务放在同一个服务器内，耦合度就会越来越大，此时就可以按照不同业务维度来拆分。
以电商为例，有用户、订单、商品服务；随着业务复杂度提升，可以将1个服务垂直拆分为3个业务模块，3个独立的业务数据库，部署在3个不同的容器，对外也有三个不同的子域名，通过单点登录来实现登陆一次；
存在问题： 当用户服务查询订单信息时，也需要维护订单的信息，而订单在订单服务内本身也存在，就会存在冗余代码，代码的耦合性提升；当订单结构有一些变化，上层依赖都需要做更改；为解决这个问题，引入了服务化的概念SOA
4. SOA 面向服务的编程
以某一种特定规范定义服务；在原3个服务层和3个数据库层之间加一套服务层； 特点是只提供一些公共的基础服务的接口；核心目标是通过服务的流程化提高业务的灵活性；主要解决数据的互联互通、业务的重用以及信息孤岛的问题；
存在问题： 调用关系紊乱，维护接口地址繁多。
引入ESB服务总线。
存在优化的可能性：当业务复杂度进一步提升，服务根据具体业务拆分为更细的模块来减少耦合
5. 微服务，强调服务的粒度
微服务降低服务的耦合度； 用户有用户、账户、积分，此时可拆分为 用户服务、账户服务、积分服务； 订单服务可以拆分为 订单、交易、支付服务；
当SOA细粒度之后，也就有了微服务化；微服务强调的是服务的解耦，更像是一种思想的提炼；(SOA 面向服务、微服务强调服务的粒度)多个微服务组成SOA服务；
微服务带来的问题：底层服务由10个变成100个，带来的底层系统资源、运维资源是否成熟，软件交付链路、底层基础化信息的演进，更加强调基础化运维的重要性(docker、k8s)
微服务 SOA区别 ：
SOA 面向服务，核心目标是通过服务的流程化提高业务的灵活性；主要解决数据的互联互通和业务的重用，信息孤岛的问题；
微服务强调服务的粒度，强调服务的解耦；
二、微服务技术组件、架构
分布式架构
两个特点：
1.分布性 ，分布在不同的计算机节点上
2.远程通信，来完成数据交换
1. Spring Cloud 生态
https://spring.io/projects/spring-cloud
Spring Cloud生态：提供了快速构建微服务的技术组件，不需要在造轮子
内部也集成了两套公司的微服务体现，奈飞(Spring Cloud Netflix)和阿里(Spring Cloud Alibaba)
Spring Cloud命名规范
由 大版本+小版本 组成；
大版本：基于伦敦地铁站站名来命名，从A、B、C、D、E...G、H。
小版本：SR(正式发布版本)、RC(后续发布版本)、MQ/M2(里程碑，预览版本)、GA(稳定版本)
目前为H: Hoxton SR7 ，正式发行的第7个版本
这样命名是因为Spring Cloud本身整合了许多开源组件，像Zookeeper、Redis、Sleuth、Dubbo等，这些组件本身存在许多版本，在使用时如何保证这些组件的兼容？
Spring Cloud在A、B。。。每个版本的pom文件中定义了所使用的不同组件的版本号，进行了组件之间的兼容覆盖。
2. 架构实现
