微服务（1）
【微服务】（1）
1. 微服务相关技术栈
微服务只是分布式架构中的一种，而SpringCloud只是解决了服务拆分时的服务治理问题，至于其他的分布式的更复杂的问题并没有明确的给出解决方案，所以微服务不仅仅包含SpringCloud，还包含一些其他的~
对于SpringCloud相关的微服务(架构)治理工作（大概了解，先不关注原理）
- 服务拆分
- 每一个服务单元我们称之为一个微服务；一个微服务的多个实例称之为集群
- （实例代表的含义就是此微服务逻辑的实现业务的对象，是一个实体，而微服务是一个业务，是虚的）
- 这样就降低耦合度，方便管理与开发、维护、更新…
- 注册中心
由于调用关系复杂，所以通过人力来解决是不太现实的
而引入注册中心：
- 每个服务都需要向注册中心“注册”，注册中心就会记录每一个服务信息（ip、端口、干啥业务…）
- 一个服务调用另一个服务的话，就是找注册中心“要”，“拉取”对应服务的信息
- 配置中心
每个服务都有配置文件，难道我们要逐个修改吗？
配置中心可以进行配置管理：
- 之后要修改配置，找配置中心，他会通知相关微服务，进行配置的热更新
- 服务网关
用户发来的请求，咋知道访问哪个服务呀，这个时候就需要一个指路人：服务网关（并且，对用户身份啥的也有一些检验）
- 最后服务作用于数据库
这里数据库写成一个，画是这么画，但是现实是一个服务对应一个数据库，数据库也有集群…以后再说，这里先放心~
SpringCloud基础上，微服务还涉及分布式缓存：
- 放在内存运行，提高效率，减少数据库压力…
- 分布式应对高并发等等…
海量数据，复杂搜索，统计分析还需要用到分布式搜索：
异步通信的消息队列组件MQ：
- 利用异步通信，提高吞吐能力
- 异步的概念不多说，不懂的可以去查
便于排查问题的分布式系统监控链路追踪和日志服务：
由于微服务的数量巨大，需要持续集成：
- 自动化编译的Jenkins
- 自动化生成打包生成镜像的docker
- 自动化部署的kubernetes和rancher
这些东西结合起来，才是完整的微服务技术栈！
而这蕴含什么知识点，我们要怎么学习这些知识呢？
2. 微服务学习路线
差不多这些：
分类后：
整理后：
- 分不同的篇章：实用、高级、面试
所以微服务专栏将以实用用篇、高级篇、面试篇的分层讲解，路线跟上图差不多，是一条不错的路线哦，墙裂推荐(๑•̀ㅂ•́)و✧，敬请期待！
- 除了图中的内容，还会结合案例进行讲解！
3. 认识微服务架构
随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？
3.1 单体架构
单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
单体架构的优缺点如下：
优点：
- 架构简单
- 部署成本低
缺点：
- 耦合度高（维护困难、升级困难）
并且，在同一个项目里，代码量庞大，光是打包部署就要花不少的时间，效率低
开发的过程中这些模块之间，代码你中有我，我中有你，耦合度高，边界模糊，改一处动万处！
耦合度高是不适合大型项目开发的！
而大项目一定会做分布式架构~
3.2 分布式架构
分布式架构：根据业务功能 对系统做拆分，每个业务功能模块 作为独立项目开发，称为 一个服务。
分布式架构的优缺点：
优点：
降低服务耦合
有利于服务升级和拓展
- 在其中一个服务修改，并不会直接影响其他服务~
缺点：
- 服务调用关系错综复杂，并且一个服务可能有一个集群，也就是多个机器来维护
- 目前的集群，浅显的认知为**“一个服务的多个一模一样的不同实例的集合，而这个集合就是集群”**，例如支付功能服务，这些不同的实例，功能都一样，都有对应的接口，只不过工作性能有区别，至于这些“打工仔”，任务如何分配？就涉及微服务架构相关知识了~
分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：
- 服务拆分的粒度如何界定？
- 哪些业务在一起呢？
- 服务集群地址和配置管理如何维护？
- 用地址访问一个集群、一个集群中的某个实例？
- 不同服务，有不同的配置文件，我们难不成逐一修改？
- 写死？肯定不行！上线改一下，代码不就不能用了！所以得支持动态的，方便维护的！
- 服务之间如何实现远程调用？
- 这可是跨服务的，怎么远程调用别的模块？例如订单模块调用支付模块…
- 服务健康状态（是否崩溃、宕机…）如何感知？
- 我怎么保证我能访问到好的服务机器呢
因此，人们需要制定一套行之有效的标准规范来约束分布式架构！
近几年应用最广泛的无非就是，微服务方案了~
3.3 微服务(架构)
微服务架构是一种经过良好的架构设计的分布式架构方案，微服务架构特征：
- 单一职责： 微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
-
自治： 团队独立、技术独立、数据独立，独立部署和交付（一个独立团队对一个服务的开发交流更加方便迅速）
- 并且不同团队用得不是同一个技术也无所谓，因为独立自治
- 面向服务： 服务提供统一标准的接口，与语言和技术无关（暴露接口）
- 隔离性强： 服务调用做好隔离、容错、降级，避免出现级联问题
对于用户相关模块，尽可能的细分，降耦合，方便后续添加更多功能服务
每个服务相互独立，并且数据独立（一个服务就对应一个数据库
（基于分布式架构的独立性的进一步体现，更加独立了！）
例如积分服务就不能直接影响用户服务的数据库，而是得调用用户服务的接口，这样就解耦合了，也降低数据库污染和降低漏洞的出现，因为别的服务对这个业务也有一套完整的“验证”，危险系数比直接影响数据库的要低~）
用户请求需要调用对应接口，通过服务网关，调用到正确的接口（因为他们部署独立，找到正确的接口并访问就需要这个入口，也就是服务网关）
不知道你有没有在学校做过团队合作的程序项目，如果不是微服务，是不是拼装代码一系列的问题接踵而至？头皮发麻？配置相关的问题也层出不穷？代码耦合高，都拉丝了？
微服务就没有这个烦恼~
微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
- 是不是之前自以为的代码高内聚低耦合，在微服务面前简直是小儿科😀
因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。
而微服务架构，是一种开发结构，一种开发思想，一种标准，一种良好的大项目开发方案，后面用到的技术栈是对此架构实现的"对症下药"！
-
两者之间是常见的“思想与落实”的区别
-
而我们要实现这么一个架构，就要有对应的技术，在使用技术的同时，不忘微服务架构的初心（也就是上面几点），因为微服架构务并不是一个强制的，不代表你不遵循他，你的项目就运行不了，他并不会从开发过程上限制你不单一职责，不自治，不面向服务，不隔离性强…
微服务架构方案较于普通的分布式架构
优点：
- 拆分粒度更小、服务更独立、耦合度更低
缺点：
- 架构更加复杂，运维、监控、部署难度提高，也就是方案落地困难
这个方案只是“纸上谈兵”
方案该怎么实现与落地？选用什么样的技术栈？
全球的互联网公司都在积极尝试自己的微服务落地方案。
其中在Java领域最引人注目的就是SpringCloud、SpringCloudAlibaba和阿里巴巴的Dubbo提供的服务治理方案了。
3.4 微服务(架构)治理落实相关的SpringCloud、SpringCloudAlibaba和阿里巴巴的Dubbo提供的服务治理方案
而他们大体都是以下模式来实现微服务治理，只不过具体用到的中间件和技术栈有所不同：
- 服务信息管理问题 - 注册中心
- 环境配置管理问题 - 配置中心
- 用户请求方向问题 - 服务网关
（大概了解即可，后面结合相关中间件和技术来理解他们怎么解决问题的）
对比几种微服务技术：
在微服务学习过程，我们以SpringCloudAlibaba为主
SpringCloudAlibaba以SpringCloud为基础的扩展，兼容很多SpringCloud的东西，所以用起来有点像SpringCloud
- 所以学习SpringCloudAlibaba相当于学习了SpringCloud
也兼容了Dubbo
- 阿里巴巴把自己的Dubbo也整合进来，有一些扩展的东西，例如Nacos，Dubbo，Sentinel…
（Nacos支持Dubbo协议调用，也支持Feign协议调用…）
以下是四种企业微服务架构落地情况：
学习SpringCloudAlibba，其实就能面对这前三类种情况啦
最后一种这种很老的技术体系，如果遇到这么老的项目，你的SpringCloudAlibaba的技能就被缴械了，你只能累一点，用Dubbo开发咯，最好就是跟0🔪建议技术升级为SpringAlibaba + Dubbo，代码不用动，换以下中间件啥的就行啦
我们需要掌握的很多，要加油💪( •_•💪)
3.5 SpringCloud
SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。
SpringCloud集成了各种微服务功能组件，也就是整合了全球各地的优良的开源组件
那我们为什么不直接用那些官方的，而是SpringCloud整合的呢？
- 这是因为SpringCloud基于SpringBoot实现了这些组件的自动装配，从而提供了**良好的开箱即用**体验。
- SpringBoot这个脚手架真的很强大！
其中常见的组件包括：
另外，SpringCloud底层是依赖于SpringBoot的，并且有版本的兼容关系，如下：
我们学习的版本是 Hoxton.SR10，因此对应的SpringBoot版本是2.3.x版本
3.6 总结
-
单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统
-
分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝
-
微服务：一种良好的分布式架构方案
①优点：拆分粒度更小、服务更独立、耦合度更低
②缺点：架构非常复杂，运维、监控、部署难度提高
-
SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件
在实战的时候更深地感受这些东西！
文章到此结束！谢谢观看
可以叫我 小马，我可能写的不好或者有错误，但是一起加油鸭🦆！文章来源：https://www.toymoban.com/news/detail-713695.html文章资源，受教于恩师：黑马程序员的个人空间-黑马程序员个人主页-哔哩哔哩视频 (bilibili.com)文章来源地址https://www.toymoban.com/news/detail-713695.html
到了这里，关于【微服务】微服务初步认识 - 微服务技术如何学习 · 认识微服务架构的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
