程序员不得不了解的微服务的现状和未来，建议收藏哦!!!

??单体架构只适合在应用初期，且访问量比较下的情况下使用，优点是性价比很高，开发速度快，成本低，但缺点也很明显，这时扩展的首先就是考虑服务器的集群处理。

1.2 集群

??针对单个服务器在访问量越来越大的情况越来越吃力的情况，我们可以考虑服务器的集群话处理。

??服务垂直化拆分后是可以大大的提高整体的服务处理能力，但是也会出现很多的冗余的代码，比如用户系统要操作订单库，要操作商品库，订单系统也有可能要操作用户库和商品库等。

业务重用，共享服务，

1.5 微服务化

??在SOA的基础上继续演进就是我们讲的微服务。SOA的服务更细粒度的拆分后就是微服务。根据时间递进。

??常用的RPC框架有:Dubbo,Google的GRPC，Apache的Thrift，微博的Motan，京东的EasyRPC等。我们通过RPC框架可以取调用服务提供者提供的服务，但有一个前提是我们要能找到这个服务。通常我们的服务部署都是集群多节点的部署，所以在消费者这端就不可能直接写死在代码里面，这时就涉及到了服务的发现问题，这时就需要另一个组件注册中心了

2.2 注册中心

??注册中心实现服务地址管理的功能，解决服务动态感知(上线，下线)。

2.4 配置中心

??在微服务架构中我们有很多个服务，而每个服务中是都会有单独的配置文件的。里面有很多的配置信息的有关联的，而且对于后期的更新维护也会非常的不方便，这时配置中心就上场了。常用的配置中心有：apollo/Nacos/disconf/zookeeper/diamond/Spring Cloud Config

2.6 限流、降级、缓存

??在现实的微服务架构中的性能是很难满足所有的用户请求，这时我们就可以通过一些措施来保证我们的核心服务的正常运转。

限流：sentinel、hystrix

降级：主动降级(订单评论、广告关闭)、被动降级

缓存：降低数据源访问频率、Redis等

容错机制：服务出现挂机，宕机之后的处理机制。

2.8 链路监控

??因为微服务中的服务实在是太多了，为了能更好的监控个服务的情况，肯定就需要链路监控服务，我们可以通过sleuth+zipkin来实现，应用层监控，系统级监控

3.1 版本 说明

• SR (发行版)
• RC (后续发行版本)
• M1/M2（PRE） 里程碑
• GA 稳定版
• BUILD-XXX 开发版

3.2 SpringCloud和SpringBoot的关联关系

大版本对应：

在实际开发过程中，我们需要更详细的版本对应：

SpringCloud版本是和SpringBoot有关联关系的，官 中可以查看：https://docs.spring.io/spring-cloud/docs/current/reference/html/

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91536 人正在系统学习中 波哥带你学编程