Serverless无服务器架构_无服务架构

对于无服务器体系结构，最终可能会更像这样：

这是一个大大简化的视图，但即使在这里，我们也看到了一些重要的变化：

1. 我们已经删除了原始应用程序中的身份验证逻辑，并将其替换为第三方BaaS服务（例如 Auth0 ）

2. 使用BaaS的另一个例子，我们允许客户机直接访问我们数据库的一个子集（用于产品列表），它本身完全由第三方（例如Google Firebase）托管。我们可能对以这种方式访问数据库的客户机具有与访问数据库的服务器资源不同的安全配置文件。

3. 前两点意味着非常重要的第三点：宠物商店服务器中的一些逻辑现在在客户机中—例如，跟踪用户会话，了解应用程序的UX结构，从数据库读取数据并将其转换为可用视图，等等。客户端正朝着成为单页应用程序的方向发展。

4. 我们可能希望在服务器中保留一些与用户体验相关的功能，例如，如果它是计算密集型的或需要访问大量数据。在我们的宠物商店中，一个例子是“搜索”。我们可以实现一个FaaS函数，通过API网关（稍后描述）响应HTTP请求，而不是像原始架构中那样始终运行服务器。客户机和服务器的“搜索”功能都从同一个数据库中读取产品数据。

5. 如果我们选择使用AWS Lambda作为FaaS平台，我们可以将搜索代码从原来的Pet Store服务器移植到新的Pet Store搜索函数，而无需完全重写，因为Lambda支持Java和Javascript，这是我们最初的实现语言。

最后，我们可以用另一个单独的FaaS函数替换“购买”功能，出于安全原因，我们选择将其保留在服务器端，而不是在客户端重新实现。它的前面也有一个API网关。在使用FaaS时，将不同的逻辑需求分解为单独部署的组件是一种非常常见的方法。

退一步讲，这个例子演示了关于无服务器架构的另一个非常重要的观点。在原始版本中，所有流、控制和安全都由中央服务器应用程序管理。在无服务器版本中，这些问题没有中央仲裁器。相反，我们更倾向于编排而不是编排，每个组件都扮演着更具体系结构意识的角色这一想法在微服务方法中也很常见。

这种方法有许多好处。正如Sam Newman在他的《构建微服务》一书中指出的那样，以这种方式构建的系统通常“更灵活，更易于更改”，无论是作为一个整体还是通过对组件的独立更新；有更好的关注点划分；还有一些引人入胜的成本效益，Gojko Adzic在这篇精彩的演讲中讨论了这一点。

当然，这样的设计是一种折衷：它需要更好的分布式监视（稍后将详细介绍），而且我们更依赖底层平台的安全功能。更重要的是，与我们最初使用的单片应用程序相比，有更多的移动部件可以让我们的大脑四处走动。灵活性和成本带来的好处是否值得多个后端组件增加的复杂性，这取决于上下文。

消息驱动的应用程序

=========

另一个例子是后端数据处理服务。

假设您正在编写一个以用户为中心的应用程序，它需要快速响应UI请求，其次，它需要捕获正在发生的所有不同类型的用户活动，以便进行后续处理。想想一个在线广告系统：当用户点击一个广告时，你想很快地将他们重定向到该广告的目标。同时，你需要收集点击已经发生的事实，这样你就可以向广告客户收费。（这个例子并不是假设我在Intent Media的前团队正是有这个需要的，他们是以无服务器Serverless的方式实现的。）

传统上，架构可能如下所示。“广告服务器”同步响应用户（未显示），并向频道发布“点击消息”。然后，“点击处理器”应用程序异步处理该消息，该应用程序更新数据库，例如，减少广告客户的预算。

在无服务器Serverless的世界中，情况如下：

你能看出区别吗？与我们的第一个示例相比，架构上的变化要小得多这就是为什么异步消息处理是无服务器技术的一个非常流行的用例。我们已经用FaaS函数替换了一个长寿命的消息使用者应用程序。此函数在供应商提供的事件驱动上下文中运行。请注意，云平台供应商同时提供messagebroker和FaaS环境，这两个系统紧密相连。

FaaS环境还可以通过实例化功能代码的多个副本来并行处理多个消息。这取决于我们如何编写原始过程，这可能是我们需要考虑的一个新概念。

解包“功能即服务”

我们已经提到了很多FaaS，但现在是时候深入研究它的真正含义了。要做到这一点，让我们看看亚马逊的FaaS产品Lambda的开场白。我给它添加了一些标记，我将对此进行扩展。

AWS Lambda允许您运行代码，而无需配置或管理服务器。(1) 使用Lambda，您可以为几乎任何类型的应用程序或后端服务运行代码（2）所有这些都不需要任何管理。只需上传你的代码，Lambda就可以处理运行（3）和扩展（4）你的代码所需的一切。你可以设置你的代码从其他AWS服务自动触发（5）或直接从任何网络或移动应用程序调用它（6）。

1. 从根本上说，FaaS是关于运行后端代码而不管理自己的服务器系统或自己的长期服务器应用程序。与容器和PaaS（平台即服务）等其他现代体系结构趋势相比，第二条长寿命服务器应用程序是一个关键区别。

如果我们回到前面的点击处理示例，FaaS会将点击处理服务器（可能是一台物理机器，但肯定是一个特定的应用程序）替换为不需要配置的服务器，也不需要一直运行的应用程序。

2. FaaS产品不需要编码到特定的框架或库。当涉及到语言和环境时，FaaS函数是常规应用程序。例如，AWS Lambda函数可以用Javascript、Python、Go、任何JVM语言（Java、Clojure、Scala等）或任何.NET语言实现。但是，Lambda函数还可以执行与其部署工件捆绑在一起的另一个进程，因此实际上可以使用任何可以向下编译到Unix进程的语言。

但是FaaS函数有很大的体系结构限制，特别是在状态和执行持续时间方面。我们很快就会知道的。

让我们再次考虑一下我们的点击处理示例。当移动到FaaS时，唯一需要更改的代码是“ main method ”（启动）代码，因为它被删除了，并且很可能是作为顶级消息处理程序的特定代码（“ message listener interface ”实现），但这可能只是方法签名的更改。其余的代码（例如，写入数据库的代码）在FaaS世界中没有什么不同。

3. 部署与传统系统非常不同，因为我们没有服务器应用程序可以自己运行。在FaaS环境中，我们将函数的代码上传到FaaS提供程序，提供程序执行资源调配、vm实例化、流程管理等所有必要的操作。

4. 水平缩放是完全自动的、弹性的，并且由提供者管理。如果您的系统需要并行处理100个请求，那么提供者将在不需要任何额外配置的情况下处理这些请求。执行您的函数的“计算容器”是短暂的，FaaS提供程序创建和销毁它们纯粹是由运行时需要驱动的。最重要的是，使用FaaS，供应商可以处理所有底层资源的供应和分配，用户根本不需要集群或VM管理。

让我们回到我们的点击处理器。比如说，我们今天过得很好，客户点击的广告是平时的十倍。对于传统体系结构，我们的点击处理应用程序能够处理这个问题吗？例如，我们开发的应用程序是否能够一次处理多条消息？如果我们这样做了，一个正在运行的应用程序实例是否足以处理负载？如果我们能够运行多个进程，自动缩放是自动的还是需要手动重新配置？使用FaaS方法，所有这些问题都已经得到了回答，您需要提前编写函数以假设水平缩放的并行性，但从那时起FaaS提供程序将自动处理所有缩放需求。

5. FaaS中的函数通常由提供者定义的事件类型触发。在Amazon AWS中，这些刺激包括S3（文件/对象）更新、时间（计划任务）和添加到消息总线的消息（例如， Kinesis ）。

6. 大多数提供者还允许将函数作为对入站HTTP请求的响应来触发；在AWS中，通常通过使用API网关来实现这一点。在我们的宠物商店示例中，我们使用了一个API网关来实现“搜索”和“购买”功能。也可以通过平台提供的API直接调用函数，可以从外部调用，也可以从同一个云环境中调用，但这是一种比较少见的用法。

状态

==

当涉及到本地（机器/实例绑定）状态时，FaaS函数有很大的限制，即存储在内存变量中的数据，或写入本地磁盘的数据。您确实有这样的可用存储，但是您不能保证这样的状态在多个调用之间是持久的，而且，更重要的是，您不应该假设一个函数的一个调用的状态将可用于同一个函数的另一个调用。因此，FaaS函数通常被描述为无状态的，但更准确地说，需要持久化的FaaS函数的任何状态都需要在FaaS函数实例之外外部化。

对于自然无状态的FaaS函数，也就是说，那些提供从输入到输出的纯功能转换的FaaS函数，这是不需要考虑的。但对于其他人来说，这可能会对应用程序体系结构产生很大的影响，尽管这并不是一个独特的概念，“十二要素应用程序”的概念有着完全相同的限制。这种面向状态的函数通常会利用数据库、跨应用程序缓存（如Redis）或网络文件/对象存储（如S3）来跨请求存储状态，或提供处理请求所需的进一步输入。

执行持续时间

======

FaaS函数通常被限制在每次调用允许运行的时间。目前，AWS Lambda函数响应事件的“超时”最多为5分钟，然后终止。微软Azure和谷歌云的功能也有类似的限制。

这意味着某些类的长寿命任务不适合FaaS功能，如果不重新架构，您可能需要创建几个不同的协调FaaS功能，而在传统环境中，您可能有一个长时间任务同时执行协调和执行。

启动延迟和“冷启动”

==========

FaaS平台在每个事件之前初始化函数实例需要一些时间。这个启动延迟可能会有很大的变化，甚至对于一个特定的功能，这取决于大量的因素，并且可能在几毫秒到几秒钟的范围内。听起来很糟糕，但是让我们更具体一点，以AWS Lambda为例。

Lambda函数的初始化要么是“热启动”（从以前的事件中重用Lambda函数的实例及其主机容器），要么是“冷启动”（创建新的容器实例、启动函数主机进程等）。在考虑启动延迟时，不出所料，最令人担忧的是这些冷启动。

冷启动延迟取决于许多变量：您使用的语言、使用的库数量、拥有的代码数量、Lambda函数环境本身的配置、是否需要连接到VPC资源等。这些方面很多都由开发人员控制，因此，作为冷启动的一部分，通常可以减少启动延迟。

与冷启动持续时间相同的变量是冷启动频率。例如，如果一个函数每秒处理10个事件，而每个事件的处理时间为50毫秒，那么您很可能只会看到每100000–200000个左右事件的Lambda冷启动。另一方面，如果您每小时处理一次事件，您可能会看到每个事件都会冷启动，因为Amazon会在几分钟后停用不活动的Lambda实例。了解这一点将有助于您了解冷启动是否会对聚合产生影响，以及您是否希望对函数实例执行“保持有效”以避免它们被丢弃。

冷启动是个问题吗？它取决于应用程序的样式和流量形状。我以前在Intent Media的团队有一个用Java实现的异步消息处理Lambda应用程序（通常是启动时间最慢的语言），它每天处理数以亿计的消息，他们不关心这个组件的启动延迟。这就是说，如果您正在编写一个低延迟的交易应用程序，那么此时您可能不想使用云托管的FaaS系统，无论您使用什么语言来实现。

不管你是否认为你的应用程序可能有这样的问题，你都应该用生产负载测试性能。如果您的用例现在不起作用，您可能需要在几个月后再试一次，因为这是FaaS供应商持续改进的一个主要方面。

API网关

=====

我们在前面讨论过的Serverless的一个方面是“API网关”。API网关是HTTP服务器，其中路由和端点在配置中定义，每个路由都与处理该路由的资源相关联。在无服务器架构中，这样的处理程序通常是FaaS函数。

当API网关接收到请求时，它会找到与请求匹配的路由配置，并且在FaaS支持的路由的情况下，它会用原始请求的表示调用相关的FaaS函数。通常，API网关将允许从HTTP请求参数映射到FaaS函数的更简洁的输入，或者允许传递整个HTTP请求，通常作为JSON对象。FaaS函数将执行其逻辑并向API网关返回一个结果，API网关又将此结果转换为HTTP响应，并将其传递回原始调用方。

amazonweb服务有自己的API网关（有点令人困惑地称为“API网关”），其他供应商也提供类似的功能。Amazon的API网关是一个BaaS（是的，BaaS！）服务本身就是一个外部服务，您可以配置它，但不需要自己运行或配置。

除了纯粹的路由请求，API网关还可以执行身份验证、输入验证、响应代码映射等。（当你考虑这是否真的是一个好主意时，如果你的蜘蛛感觉到刺痛，那么保持这个想法！我们稍后会进一步考虑。）

使用FaaS函数的API网关的一个用例是以无服务器的方式创建HTTP前端的微服务，其中包含FaaS函数带来的所有扩展、管理和其他好处。

当我第一次写这篇文章时，Amazon的API网关的工具，至少是非常不成熟的。自那时以来，这些工具有了很大改进。像aws api gateway这样的组件并不是很“主流”，但希望它们比以前少一点痛苦，并且只会继续改进。

工具集

===

上面关于工具成熟度的评论一般也适用于无服务器。2016年的情况相当艰难；到2018年，我们已经看到了明显的改善，我们预计工具会变得更好。

FaaS世界中几个优秀的“开发者用户体验”的显著例子值得一提。首先是auth0webtask，它将开发人员UX作为其工具的重要优先权。其次是微软，他们的Azure功能产品。微软一直将反馈循环紧密的visualstudio放在开发人员产品的前列，Azure功能也不例外。它提供的在本地调试函数的能力（给定来自云触发事件的输入）非常特殊。

一个仍然需要显著改进的领域是监测。我稍后再讨论。

开源

==

到目前为止，我主要讨论了专有供应商产品和工具。大多数无服务器应用程序都使用这种服务，但世界上也有开源项目。

在Serverless中，开源最常见的用途是FaaS工具和框架，尤其是流行的Serverless框架，其目的是使使用awsapi网关和Lambda比使用AWS提供的工具更容易。它还提供了大量的跨供应商工具抽象，一些用户认为这很有价值。类似工具的例子包括Claudia和Zappa。另一个例子是Apex，它特别有趣，因为它允许您用Amazon直接支持的语言以外的语言开发Lambda函数。

不过，大厂商本身并没有在开源工具派对上落在后面。AWS自己的部署工具SAM无服务器应用程序模型也是开源的。

专有FaaS的主要好处之一是不必关心底层的计算基础设施（机器、vm，甚至容器）。但是如果你想关心这些事情呢？也许你有一些云供应商无法满足的安全需求，或者你已经买了一些服务器，不想扔掉。开源能在这些场景中提供帮助，让您运行自己的“服务器式”FaaS平台吗？

是的，这方面的活动也很多。开源FaaS的最初领导者之一是IBM（使用OpenWhisk，现在是一个Apache项目），至少让我吃惊！-微软（Microsoft）开放了其Azure平台的大部分功能。许多其他自托管FaaS实现都使用底层容器平台，通常是 Kubernetes ，这有很多原因。

什么不是无服务器的？

==========

到目前为止，在本文中，我将Serverless描述为两种思想的结合：后端即服务和函数即服务。我还深入研究了后者的能力。要更精确地了解我所看到的无服务器服务的关键属性（以及为什么我认为像S3这样的旧服务是无服务器的）。

在我们开始研究非常重要的优点和缺点之前，我想再花一点时间讨论一下定义。让我们定义一下无服务器不是什么。

与PaaS的比较

========

考虑到无服务器FaaS功能与12因素应用程序非常相似，它们是否只是Heroku那样的“平台即服务”（PaaS）的另一种形式？

如果您的PaaS能够高效地在20ms内启动运行半秒的实例，那么就称之为无服务器。

换句话说，大多数PaaS应用程序并不是为了响应事件而使整个应用程序上下移动，而FaaS平台正是这样做的。

如果我是一个优秀的12要素应用程序开发人员，这并不一定会影响我如何编程和构建我的应用程序，但它确实会对我如何操作它们产生很大的影响。既然我们都是优秀的DevOps工程师，我们在考虑开发的同时也在考虑运营，对吧？

FaaS和PaaS在操作上的关键区别是可伸缩性。一般来说，对于PaaS，您仍然需要考虑如何进行扩展，例如，对于Heroku，您希望运行多少个动态节点？对于FaaS应用程序，这是完全透明的。即使您将PaaS应用程序设置为自动伸缩，您也不会将其设置为单个请求的级别（除非您有一个非常特定的流量配置文件），因此FaaS应用程序在成本方面效率更高。

既然有这个好处，为什么还要使用PaaS呢？有几个原因，但工具可能是最大的。另外，有些人使用诸如cloudfoundry之类的PaaS平台来提供跨混合公共云和私有云的通用开发体验；在撰写本文时，还没有FaaS这样成熟的平台。

与容器比较

=====

使用无服务器FaaS的原因之一是避免在操作系统级别管理应用程序进程。PaaS服务，比如Heroku，也提供了这种功能，我在上面已经描述了PaaS与无服务器FaaS的区别。另一种流行的流程抽象是容器，Docker是这种技术最明显的例子。诸如Mesos和Kubernetes之类的容器托管系统从操作系统级部署中抽象出单个应用程序，现在越来越流行。沿着这条路走得更远，我们可以看到云托管容器平台，如amazonecs和EKS，以及googlecontainer Engine，它与无服务器FaaS一样，让团队完全不必管理自己的服务器主机。考虑到集装箱的发展势头，还值得考虑无服务器FaaS吗？

基本上，我为PaaS提出的论点仍然适用于容器—对于无服务器的FaaS，扩展是自动管理、透明和细粒度的，这与我前面提到的自动资源调配和分配有关。容器平台传统上仍然需要您管理集群的大小和形状。

我还认为容器技术还不成熟和稳定，尽管它越来越接近成熟和稳定。当然，这并不是说无服务器FaaS已经成熟，但选择您喜欢的粗糙边缘仍然是当前的工作重点。

还有一点很重要，即自伸缩容器集群现在可以在容器平台中使用。Kubernetes内置了“ Horizontal Pod Autoscaling ”，像AWS Fargate这样的服务也承诺了“无服务器容器”

当我们看到无服务器faa和托管容器之间在管理和扩展方面的差距缩小时，它们之间的选择可能会归结为应用程序的样式和类型。例如，对于每个应用程序组件只有很少的事件类型的事件驱动样式，FaaS被视为更好的选择，而对于具有许多入口点的同步请求驱动组件，容器被视为更好的选择。我预计在相当短的时间内，许多应用程序和团队将同时使用这两种体系结构方法，看到这种使用模式的出现将是一件非常有趣的事情。

NoOps

=====

Serverless并不意味着“没有操作”–尽管它可能意味着“没有系统管理员”，这取决于你在Serverless兔子洞里走了多远。

“Ops”不仅仅意味着服务器管理。它还意味着至少监视、部署、安全、联网、支持，以及一些生产调试和系统扩展。这些问题在没有服务器的应用程序中仍然存在，你仍然需要一个策略来解决它们。在某种程度上，在一个没有服务器的世界里，Ops是很困难的，因为很多都是全新的。

系统管理员仍然在发生你只是外包它与无服务器。这不一定是一件坏事（或好事），我们外包了很多，它的好坏取决于你正试图做什么。不管是哪种方式，在某个时候抽象可能会泄漏，您需要知道某个地方的人类系统管理员正在支持您的应用程序。

Stored Procedures as a Service

==============================

我看到的另一个主题是无服务器FaaS是“存储过程即服务”。我认为这是因为FaaS函数的许多示例（包括我在本文中使用的一些）都是与数据库紧密集成的小块代码。如果这就是我们可以使用FaaS的全部，我认为这个名字会很有用，但是因为它实际上只是FaaS功能的一个子集，我不认为用这些术语来考虑FaaS是有用的。

也就是说，值得考虑的是FaaS是否与存储过程有一些相同的问题，包括Camille在上面提到的tweet中提到的技术债务问题。从使用存储过程中得到的许多经验教训值得在FaaS的上下文中回顾，看看它们是否适用。请考虑存储过程：

1. 通常需要特定于供应商的语言，或者至少需要特定于供应商的语言框架/扩展

2. 很难测试，因为它们需要在数据库上下文中执行

3. 很难进行版本控制或将其视为一级应用程序

虽然并非所有这些都必须适用于存储过程的所有实现，但它们肯定是可能遇到的问题。让我们看看它们是否适用于联邦航空局：

（1） 对于我目前看到的FaaS实现来说，这绝对不是一个问题，所以我们可以马上把它从列表中删除。

对于（2）来说，既然我们处理的是“仅仅是代码”，那么单元测试肯定和其他代码一样简单。集成测试是一个不同的（合法的）问题，我们将在后面讨论。

对于（3），同样由于FaaS函数是“只编码”的，所以版本控制是可以的。直到最近，应用程序打包还是一个值得关注的问题，但是我们已经开始看到这里的成熟，有了Amazon的无服务器应用程序模型（SAM）和我前面提到的无服务器框架之类的工具。2018年初，亚马逊甚至推出了“无服务器应用程序存储库”（SAR），为企业提供了一种基于AWS无服务器服务的应用程序和应用程序组件分发方式。

好处

==

到目前为止，我一直试图坚持自定义和解释无服务器架构的含义。现在我将讨论这种设计和部署应用程序的方法的一些优点和缺点。您绝对不应该在没有充分考虑和权衡利弊的情况下决定使用Serverless。

让我们从彩虹和独角兽的土地开始，看看无服务器的好处。

降低运营成本

======

Serverless最简单的就是一种外包解决方案。它允许你付钱给某人来管理服务器、数据库甚至应用程序逻辑，否则你可能会自己管理。由于您使用的是其他许多人也将使用的预定义服务，因此我们看到了规模经济效应：您为托管数据库支付的费用更少，因为一个供应商正在运行数千个非常相似的数据库。

在您看来，降低的成本是两个方面的总和。第一种是纯粹通过与他人共享基础设施（如硬件、网络）获得的基础设施成本收益。第二个是劳动力成本收益：与自己开发和托管的同等系统相比，您可以在外包的无服务器系统上花费更少的时间。

然而，这种好处与基础设施即服务（IaaS）或平台即服务（PaaS）的好处并没有太大区别。但我们可以通过两种关键方式来扩展这一优势，一种是针对无服务器的BAA和FAA。

BaaS：降低开发成本

===========

IaaS和PaaS的前提是服务器和操作系统管理可以商品化。另一方面，无服务器后端即服务是整个应用程序组件商品化的结果。

身份验证就是一个很好的例子。许多应用程序编写自己的身份验证功能代码，其中通常包括注册、登录、密码管理以及与其他身份验证提供者的集成等功能。总的来说，这种逻辑在大多数应用程序中都非常相似，而且像Auth0这样的服务已经被创建，允许我们将现成的身份验证功能集成到我们的应用程序中，而无需我们自己开发。

在同一个线程上是BaaS数据库，比如Firebase的数据库服务。一些移动应用程序团队发现，让客户端直接与服务器端数据库通信是有意义的。BaaS数据库消除了大量的数据库管理开销，并且通常以无服务器应用程序所期望的模式为不同类型的用户提供适当授权的机制。

FaaS：扩展成本

=========

无服务器FaaS的一个好处是，正如我在本文前面所说的——“水平扩展是完全自动的、有弹性的，并且由提供商管理的。”这有几个好处，但在基本的基础设施方面，最大的好处是您只需支付所需的计算费用，在AWS Lambda的情况下，下降到100ms边界。取决于你的交通规模和形状，这可能是一个巨大的经济胜利给你。

示例：偶尔请求

=======

假设您运行的服务器应用程序每分钟只处理一个请求，处理每个请求需要50毫秒，一小时的平均CPU使用率为0.1%。如果将此应用程序部署到自己的专用主机上，则效率非常低。一千个其他类似的应用程序都可以共享一台机器。

无服务器FaaS抓住了这一低效，以更低的成本为您带来好处。使用上面的示例应用程序，您每分钟只需支付100毫秒的计算时间，这是总时间的0.15%。

这有以下连锁反应的好处：

• 对于负载需求非常小的准微服务，它支持按逻辑/域分解组件，即使这种细粒度的操作成本在其他方面可能会很高。

• 这样的成本效益是一个很大的民主化。如果公司或团队想要尝试一些新的东西，那么当他们使用FaaS来满足他们的计算需求时，他们的运营成本就非常低。事实上，如果您的总工作量相对较小（但并非完全不重要），那么由于FaaS供应商提供的“免费层”，您可能根本不需要为任何计算付费。
  自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书+2021年最新大厂面试题。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书+2021年最新大厂面试题。
[外链图片转存中…(img-TybJ7Hen-1713382186794)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！