前后端分离架构有利于将微服务在技术层面上解耦，后端微服务可以专注于实现对后端服务和资源的管理，而不用再关注与用户交互的逻辑验证等问题。
前后端分离有利于微服务中的各组件的演进和组合，微服务架构细粒度的服务可以让不同前端共享不同后端，通过“搭积木”的方式实现服务的复用和独立的演进，如下图所示。
事件驱动技术
在单体架构下，系统的复杂性在于如何做好模块之间的解耦，因为模块依然存在于同一个进程中，实现进程内的并发处理和多线程模型的管理是单体架构的主要工作。所以单体架构的瓶颈往往是CPU，不适合网络I/O密集型的计算处理场景。而在微服务架构下，因为细粒度的服务之间的交互主要通过分布式网络进行，而事件驱动架构为微服务提供了更多的跨网络集成优势。
● 基于事件的体系结构是异步的，不存在网络阻塞。在提供服务之前，我们必须考虑网络的局限性。选择REST同步调用方式存在服务调用依赖问题，会产生级联消息雪崩效应，而选择事件机制我们不用担心同步调用的问题。
● 基于消息队列的异步消息处理机制。相比请求/响应模式的服务集成方式，采用Broker代理的服务集成方式可实现服务之间的解耦，同时可以提高服务的性能、可靠性、可扩展性。
然而，事件驱动框架也会在消息一致性、消息的监控和传输上给系统带来额外的技术复杂性。
● “协同”优先“编排”原则。事件编排机制会由“中心大脑”
来领导并驱动整个流程，这个大脑就像交响乐队中的指挥；事件协同机制会预先说明清楚系统中各个部件的职责，而把具体怎么实现留给各个部件。总的来说，事件编排机制的缺点是明显的，中心控制点承担了太多职责，它会成为网状结构的中心枢纽。而事件协同机制不仅可以降低系统的耦合性，还可以让我们以更加灵活的方式修改现有系统。
● CQRS（Command and Query Responsibly Separate，命令查询职责分离），是介于脚本驱动和领取驱动之间的一种服务建模与数据交互模式，是事件驱动领域中被广泛使用的一个概念，通过CQRS可以解决数据读写交叉问题，并能有效降低业务逻辑的复杂性。
服务监控与治理
=======
在单体架构时代，因为所有服务都集中在少数几个系统中，系统之间的相互调用关系相对简单，在出现故障时，可以将问题根源锁定在有限的系统范围内并定位问题。而在微服务架构下，众多微服务实例之间有频繁的分布式跨网络协作、相互远程调用，这时如果没有一整套服务治理方法，帮助我们保证SLA（Service-Level Agreement，服务等级协议）、增强服务治理水平、提升微服务的治理与运维效率，那么微服务的转型之路将举步维艰。
技术团队关注的焦点往往是架构的实现和业务建模，容易忽略微服务架构带来的一系列负面影响，通过微服务监控与治理可以全方位地掌控当前服务的运行状态和资源利用情况，可以说，服务治理与监控既是微服务架构在平台层面的核心工作，也是微服务应用“长治久安”的前提。通过微服务治理能力的提升，可以提供对业务应用的快速响应能力、保证业务的健康稳定及持续演进；在技术上，可以帮助微服务的开发和运维人员实时地掌握微服务的运行状态，以及进行问题定位和故障恢复。
在服务治理的技术选型上，Spring Cloud提供了服务治理的一站式解决方案。同时，微服务框架结合众多技术组件可以提供Metrics指标监控、日志监控、调用链等信息监控、健康检查和告警通知等功能。Metrics监控主要依赖于时间序列数据库，目前较成熟的产品有Prometheus 和 OpenTSDB； 我 们 可 以 采 用 ELK （ Elasticsearch 、Logstash、Kibana三个技术框架缩写）技术栈实现日志的归集、存储、搜索和可视化报表查看等；可以采用Spring Cloud Sleuth日志收集工具包，结合Zipkin和HTrace，作为Spring Cloud的一种分布式追踪解决方案。
容器和自动化技术
========
容器和自动化技术可以说是微服务规模化发展需要解决的首要问题。基于容器的部署和交付无论在软件开发领域，还是运维相关领域，都带来了巨大的技术颠覆。通过自动化交付部署可以将开发与运维环节打通。交付物的标准化使得我们可以“标准化”地交付应用及它所依赖的运行环境。Docker容器一次构建、多次交付的特性可以使微服务具备了更好的可移植性、可复用性。
很多人把容器化和微服务架构混为一谈，认为自己的服务部署到了容器后，系统就是一个微服务架构了。其实二者存在本质上的差异。可以说，一个巨石型单体架构即使部署到了容器上，依然无法改变它架构上的“拙劣”。
目前容器技术仍然是微服务架构最佳的运行时环境和平台，也很好地支撑了微服务架构去中心化、细粒度、容错、伸缩的特性。如下图所示，是虚拟机与容器不同的隔离机制。
虚拟机
容器
使用传统虚拟机的应用存在如下运维弊端：
● 部署非常慢、成本非常高、资源浪费。
● 难以迁移和扩展。
● 服务与硬件厂商提供的特性绑定。
使用容器对微服务架构进行自动化运维的优势：
● 容器的资源开销更小，Docker本身共享操作系统内核，容器可以节省更多物理机资源。
● 在开发和运维之间搭建了一座桥梁，是实现DevOps的最佳方案。
● 容器可以对软件和其依赖的标准镜像格式打包，保证应用在不同运行环境下的统一交付，解决环境差异问题和大规模的交付部署问题。
● 容器本质上相当于一个进程，每个容器都可以看作一个不同的微服务进程，因此可以独立升级，与底层共享操作系统，性能更加优良，系统负载更低，在同等硬件资源条件下可以运行更多的应用实例，更充分地利用系统资源。
● 在没有适合的工具和自动化运维的情况下，使用微服务架构会导致灾难。目前基于容器技术和Kubernetes技术的平台已经成为微服务交付和管理的最佳平台。
云原生12要素
=======
Gartner定期发布的技术成熟度曲线可以帮助我们方便地评估技术的成熟度，同时帮助我们制定战略，即采用怎样的技术工具。Gartner最新发布的技术影响力和普及模式与成熟度分析说明，微服务架构已经在中国全面进入成熟落地阶段，从全球来讲，很多知名IT企业和公司，像亚马逊、Netflix、阿里巴巴，已经采用微服务架构重塑了自己的核心业务系统。当前，很多公司为了节省成本、减少对基础硬件设施的投入，纷纷选择采用公有云或者私有云的方式管理公司的应用服务和基础设施。
云原生12要素（如下图所示）是基于云的架构设计和开发模式需要具备的一套全新的理念，也是云原生应用开发的最佳实践原则。
● 要素1：基准代码
基准代码和应用之间总是保持一一对应的关系：一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用都可以分别使用云原生12要素进行开发。
● 要素2：依赖显式声明依赖关系，应用程序不会隐式依赖系统级的类库。要通过依赖清单，确切地声明所有依赖项。此外，在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。像Java语言使用的Maven打包软件或者Cradle都可以显式声明依赖。
● 要素3：配置
通常应用的配置在不同部署环境（预发布、生产环境、开发环境等）中会有很大差异。Factor推荐将应用的配置存储于环境变量中。我们可以非常方便地在不同的部署环境中修改环境变量，却不动一行代码。
● 要素4：后端服务
这里的后端服务指的是应用运行所依赖的各种服务，例如数据库、消息代理、缓存系统等，对于云原生应用来说，往往还会有日志收集服务、对象存储服务及各种通过API访问的服务，可以把这些服务作为外部的、通过网络调用的资源。
● 要素5：构建、发布和运行
构建、发布和运行三个阶段需要有严格的界限，部署工具应该明确每个发布版本的唯一发布ID对应的构建版本。
● 要素6：进程
应用进程的内部不要保存状态信息，以一个或多个无状态的进程运行应用，任何状态信息都应该被保存在数据库、缓存系统等外部服务中。应用实例之间的数据共享也要通过数据库和缓存系统等外部服务进行，直接的数据共享不但违反无状态原则，还引入了串行化的单点，这会给应用的横向扩展带来障碍。
● 要素7：端口绑定
通过端口绑定提供服务，应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。
● 要素8：并发通过进程模型进行扩展，任何计算机程序一旦启动，就会生成一个或多个进程。互联网应用采用多种进程运行方式，而不是线程方式，进程是“一等公民”。
● 要素9：易处理
最后
分享一些资料给大家，我觉得这些都是很有用的东西，大家也可以跟着来学习，查漏补缺。
《Java高级面试》
《Java高级架构知识》
《算法知识》
最后
分享一些资料给大家，我觉得这些都是很有用的东西，大家也可以跟着来学习，查漏补缺。
《Java高级面试》
[外链图片转存中…(img-8yqfLP5P-1714543423226)]
《Java高级架构知识》
[外链图片转存中…(img-AgYuL43K-1714543423226)]
《算法知识》
[外链图片转存中…(img-QH3qJMf2-1714543423227)]
2325
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
