微服务技术的重要性
- 目前各大电商平台，国企，事业单位，银行，都在建立高并发稳定的信息系统，基本都在使用微服务框架技术作为架构。已经不是趋势，而是实实在在用到的技术，标书里明确要求要使用云平台，微服务技术。应聘去做单机版系统的程序员工资一般不会高
- JAVA工程师拿到高薪必须掌握的技能
3.笔试面试的时候不会问Jdk，默认都会
Map如何遍历
HashCode与equals的区别
而是问
Redis 缓存穿透、缓存雪崩、缓存击穿
SpringcloudALibaba相关技术
4.传统小型公司、小型软件的应用是单体的，一个应用装在一个web服务器上
目前的商业应用大部分是分布式的
不是一个应用只装在一台机器上，而是一个应用分别部署在几百个容器里，几百个机器上。 此时应用不放在一个JVM上，而是放在大几十个JVM上。
额外引申的知识：原本一个JDK中学到的东西在分布式环境下不再适用。
比如银行取钱money=money-10万元;这一段程序，在一个jvm里，你的电脑上是没有问题的。但是如果有1000个程序同时执行这段程序是有问题的，如何保证一个JVM里程序-10万元的时候，其他JVM里不+100，这就是保证数据的一致性和完整性。这就是分布式锁的问题，我们学到的单机应用里synchronized 同步对象锁，只是在一个JVM里操作 ，在这已经不管用了。
我们学习多线程的时候会讲到
怎么办。 用分布式锁来实现
实现分布式锁的三种方式
基于数据库的分布式锁
基于Redis的分布式锁
基于Zookeeper的分布式锁
技术框架的演变
1.单体架构
单体应用架构（Monolithic Architecture）是一种传统的应用架构模式，将应用程序作为一个整体部署和运行在单一的软件实体中。在单体应用架构中，应用的各个功能模块紧密地耦合在一起，共享相同的运行环境和数据库。
单体应用架构适用于一些简单和小规模的应用场景，如内部管理系统、小型电子商务网站等。这种架构模式通常适用于初创企业或小型业务，因为它具有快速开发、部署和维护的优势。
2.垂直应用架构
随着企业业务的不断发展，发现单节点的单体应用不足以支撑业务的发展，于是企业会将单体应用部署多份，分别放在不同的服务器上。但是，此时会发现不是所有的模块都会有比较大的访问量。如果想针对项目中的某些模块进行优化和性能提升，此时对于单体应用来说，是做不到的。于是乎，垂直应用架构诞生了。
以电商系统为例，在垂直应用架构下，我们可以将整个电商项目拆分为：电商交易系统、后台管理系统、CMS管理系统等。
我们将单体应用架构拆分为垂直应用架构之后，一旦访问量变大，我们只需要针对访问量大的业务增加服务器节点即可，无需针对整个项目增加服务器节点了。
3.分布式架构
随着技术的进步，之后出现了SOA面向服务的架构，当时接口和接口通过编写webservice接口来调用，随着时间的推移分布式架构就诞生了。
1.soa架构
SOA架构通常使用集中式的服务总线来协调服务之间的通信
SOA架构仍然是有问题的，esb企业服务总线是唯一的通信节点，万一这个节点挂掉，就是灾难性的。
2.微服务
微服务的前世今生
早期的电商平台，所有功能代码都部署在一个服务器上
早期电商平台遇到的问题
在双11的时候一个人下单没有问题，在高峰时期，千万人的同时下单，程序卡死的同时。
浏览功能，物流功能都不能用，就像idea里你关闭了程序，应用就不能访问了
解决方案
1.功能隔离。各模块单独隔离，一个功能出问题，不会影响另外一个。也就是各个功能，单独部署在一个服务器上。
比如下订单功能挂了，不会影响查看物流功能
2.保证每个功能的健壮
如何保证下订单功能永远不会挂掉
是否能将立即购买程序（服务）启动上万个，一个立即购买程序不能访问，会自动切换到另一个立即购买程序
微服务就是为了解决高并发下系统的稳定性，健壮性问题，将整个应用程序拆分成多个子应用,子应用再继续拆分为服务，服务部署很多个，应用之间通过url请求来访问。
微服务的产生
微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能
各个微服务之间的访问通过url来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。
例如将用户服务，订单服务，商品服务单独做成一个个应用程序,可以部署在多个单位的服务器上。理论上一个放在北京，一个放在俄罗斯也是可以的。
微服务的特点
他们是小型的，独立的和松散耦合的。
它们是独立部署的。 团队可以更新现有微服务，而无需重新生成和重新部署整个应用程序。
它们使用良好定义的 API 相互通信。 每个服务的内部实现细节均对其他服务隐藏。
它们支持多语言编程。 例如，可以使用go语言做一个服务，php做一个服务。
微服务的电商架构图
微服务技术是Spring Cloud技术吗？
SpringCloud仅仅是解决了拆分的服务治理问题，至于分布式其他的问题并没有解决方案。比如分布式锁，分布式事务。
微服务技术对比
1.dubbo技术
dubbo技术：在2012年阿里巴巴将Dubbo技术就已经开源了。但它并不是严格意义上的微服务技术。注册中心是用的zookeeper，其实zookeeper主要是做集群管理。配置中心和服务网关都没有实现。
服务监控和服务保护是用的：dubbo-admin,它的功能比较单一，只是来统计一下调用时的相应时间。
2.SpringCloud技术
SpringCloud并不是新发明，而是把各个公司的开源技术进行了一个整合。从而形成了一套完整的技术体系。所以说SpringCloud技术比较完善。目前停止更新
注册中心：有专业的Eureka。
服务远程调用：用的是基于http协议标准的Feign技术。比如说Controller中遵循Restful接口。
配置中心：SpringCloudConfig
服务网关：SpringCloudGateway遵循了响应式编程，吞吐能力比较强。
服务保护：Hystrix是一个比较强大的服务保护技术。可以实现服务隔离、熔断等。
3.SpringCloudAlibaba
SpringCloudAlibaba形成一套完整的技术栈。实现了自己的注册中心、自己的配置中心、自己的服务监控，事务监控等等组件。
它是实现了springCloud标准接口，统一的接口规范，所以用起来跟SpringCloud没有什么学习成本。
注册中心： Nacos强大之处在于，既支持Dubbo调用，又支持Feign调用。也就是说在一个微服务中既支持支持Dubbo接口，也支持Feign接口。
也就是说SpringCloudAlibaba兼容Dubbo和SpringCloud两种架构。
为什么要选择学习SpringCloudAlibaba
随着技术的迭代更新,springCloud对应的组件停止更新服务,所以为了针对这一情况,国内的大多数企业选择提前准备,所以SpringCloudAlibaba就出世了
而且springCloudAlibaba是经过多年双11的锻炼出来的，因为是国产的。 所以国企，电信，银行、政府在做微服务的时候都把springCloudAlibaba做为微服务技术的首选。
微服务技术有哪些
