微服务架构及常见微服务技术栈
一、微服务架构介绍
微服务是什么？
单体服务中拆分出来某个服务，称为微服务。单一应用程序构成的小服务。
微服务技术栈有哪些？
微服务技术栈除了SpringCloud，还有很多，比如常见的Redis、MQ也在这个范围，甚至是云原生也是微服务技术栈中的一部分。
微服务架构是什么？
一种思想，源自于马丁·福勒的一篇论文，将一个应用基于业务分解成一些小型而自治的架构思想。
关键点：
独立的微服务：可以单独运行、更新、拓展，和其他服务之间做到解耦，并且服务之间最好要有独立的数据库，每个微服务都可以做到弹性伸缩。
单一职责、高内聚：每个服务最好都是基于特定的业务功能进行构建的。
云原生：将微服务运行在多台Pod容器内，并且还要提供各种监控的操作。
二、微服务架构的优势与挑战？
优势
灵活性： 每个服务可以使用不用的语言去构建。整个产品是可以做到异构的。（Java，Python，Golang）
可拓展：大流量的服务可以单独进行扩容，不影响其他服务。
独立部署：更新一个微服务，不需要重启整个系统，对于敏捷式开发支持效果更好。
团队自治：小团队服务特定的业务线，团队成员之间的干扰会特别少，对于敏捷式开发支持效果更好。
容错性：不会因为某个服务的宕机导致整个系统不可用。
......
经历回顾：先前，在带领学生团队开展大创项目时，我曾想过一个问题，我们软件采用微服务还是单体？我仅对这俩进行分析，当时项目之初，想着大家都能参与进来，4名后端同学进行项目的搭建，在一期需求的时候，刚对项目整体进行搭建，有的负责日志、异常处理等，有的负责逆向工程、基础功能，项目整体架构的搭建。我印象很清晰，有天彻夜修改一个问题，因为是Git协作开发，因缺陷导致项目无法运行，其他同学无法进行开发调试工作，而这也恰恰体现出单体项目团队自治的薄弱点。当时采用敏捷开发，哈哈，这会想来也是有点假敏捷了。项目分期一方面赶工，另一方面却想要留下文档，从需求分析、数据库设计、接口定义、代码文档等，如果想要从企业的角度出发、从敏捷开发的“灵魂”出发，留下成篇文档显然不行。
挑战
分布式复杂性：服务间通讯、网络延迟、数据一致性问题。（分布式锁、事务、分布式ID、分布式调度等）
运维难度：部署、监控、日志分散。
性能问题：服务间通讯/调用 是存在网络IO成本的，无法规避，所以需要各种方式进行优化程序。
人力、金钱成本：架构设计会导致基础人力成本增加、服务器的成本，运维监控成本的提高。
三、微服务常见的组件
服务的注册与发现：
组件：Nacos、Eureka、Consul、Zookeeper……
解决的问题：服务之间调度的地址问题还有服务上下线监控相关等
负载均衡（客户端负载均衡）：
组件：Ribbon、LoadBalancer……
解决的问题：基于 服务名 拉取到多个服务地址信息后，在里面选一个
配置中心：
组件：Nacos、Config、Apollo……
解决的问题：统一管理各个服务组件的配置信息、还有配置动态刷新的效果……
熔断降级：
组件：Hystrix、Sentinel……
解决的问题：解决服务雪崩，给接口提供快速失败（限流、异常、超时、熔断）的手段，返回托底数据……
API网关：
组件：Zuul、Gateway……
解决的问题：后端服务的入口，可以在这统一的做一些限流、鉴权等操作……
负载网关：
组件：Nginx、Kong、Tengine……
解决的问题：客户端请求的入口，在第一步抗住客户端的大流量，负载到各个API网关服务……
消息队列：
工具：RabbitMQ、RocketMQ、Kafka、Stream……
解决的问题：解耦、异步、削峰、大数据传输……
链路追踪：
工具：Sleuth + Zipkin、Skywalking
解决的问题：快速定位问题，更舒服的方式查看整个调用链路……
容器化：
工具：Docker、Containerd、Kubernetes、GraalVM……
解决的问题：快速部署、弹性伸缩…………
监控、日志：
工具：Prometheus + Grafana、ELK、EFK
解决的问题：监控各个容器和硬件资源，收集日志，方便错误排查……
CI、CD：
工具：Jenkins、KuberSphere……
解决的问题：自动化测试、自动化部署
存储………………