xiaoli8748的专栏

从本篇开始，梳理关于软考的「系统架构设计师」的文章，如果不对，还望指出。【软件架构】软件架构（也可称为体系结构）是用来刻画软件系统整体抽象结构的一种手段，软件架构设计也是软件系统开发过程中的一个重要环节。章节在实际考试中分数占用率较少，多数会出现一个选择题，但是针对我们开发人员来讲了解基础和背景，立志成为一个系统架构设计师，却是一个垫脚石。

系统架构设计师 (System Architecture Designer)是项目开发活动中的众多角色之一，它可以是一个人或一个小组，也可以是一个团队。架构设计师是系统开发的主体角色，构设计师的成果是创建架构，系统开发中架构设计师是整个系统的核心。架构设计师是负责系统架构的人、团队或组织 (IEEE1471-2000)。

RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。当垂直应用越来越多时，应用之间的交互不可避免，可将共用的基础服务或核心模块抽取出来作为独立服务，逐渐形成稳定的服务中心，使前端应用灵活快捷的面向多变的市场需求。​​​​​​分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。将基础业务功能进行了抽取，系统间相互独立调用，降低服务耦合，提高了代码的复用率和开发效率。系统间的耦合度变高了，调用关系错综复杂，难以维护。服务的调用关系如何管理？

单体架构是一种传统的软件架构设计模式，它是将一个软件系统作为一个整体来开发、部署和运行。单体架构的应用程序通常由三个主要部分组成：用户界面、应用逻辑和数据库。这三个部分都在同一个代码库中，由同一个开发团队维护和开发。单体架构的应用程序通常是一个单一的可执行文件，部署和运行都比较简单。代码简单、易于理解和开发部署和运行比较简单可以共享资源，节省成本可以方便地进行单元测试难以扩展，因为整个应用程序必须一起扩展难以维护，因为代码库很大，难以理解和修改。

对于知识体系体系的构建，一直都是学习和工作中，非常重要的问题。--------------------------------------消息队列知识技术体系举例------------------------------------------------------

单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝微服务：一种良好的分布式架构方案①优点：拆分粒度更小、服务更独立、耦合度更低②缺点：架构非常复杂，运维、监控、部署难度提高SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件。

微服务架构是在SOA架构的基础上进行进一步的扩展和拆分。微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成。分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务，供其他调用者消费，以实现服务的共享和重用。

微服务（Microservices）是一种软件架构风格，把一个单独的应用程序开发为一套小服务，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。网关处理器还会依次应用配置的过滤器链，对请求进行处理和转换。在微服务架构中，一个完整的请求可能经过十几个服务，如果某一个服务出了问题，排查起来非常困难，所以就需要进行链路追踪来帮助排查问题。服务注册信息复制：当一个服务实力向Eureka Serve注册时，每个Eureka Server实例都会复制其它实例的注册信息，以保持数据的一致性。

同时，就算部署业务程序的机器损坏，也不会丢失系统数据，在一定程度上也提升了系统的抗风险性。显然，这种方式虽然成本低，数据交换快，但并不能支撑太大的访问量，当流量增大时，系统很可能因为CPU、内存、带宽、磁盘等各因素出现性能问题，而一旦遇到瓶颈，为了保证系统正常运行，集“前端、后端、运维、测试、售后……以数据库为例，数据库由于并发影响，读取数据越来越慢，所以阻塞在后端服务中等待数据返回的请求越来越多，入站流量远大于出站流量，长此以往，后端服务线程数超负荷，系统再次出现响应缓慢、无返回等严重事故。

将一个大型应用拆分成多个相互独立的小型应用成为解决单体应用的一种方案，这就是垂直架构（也成为“竖井式架构”）。垂直架构相较于单体架构而言，进行了部分解耦，但是不够彻底，在各个子系统相互依赖的代码和模块中，存在重复代码拷贝和模块功能重复开发的情况。优点：对系统进行了拆分，实现了流量分担，解决了并发问题，可以正对不同模块进行优化，方便水平扩展、负载均衡，容错率提高。当业务复杂度增加、访问量逐渐增大出现高并发时，单体架构无法满足需求，可以根据业务功能对系统进行拆分，以提高访问效率。

企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务的构架。面向服务的架构（SOA）是一种设计方法，也是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。的特性，使得企业可以模块化的增加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务，从而保护了现有的IT基础建设投资。

这个系统架构图展示了一种模块化、层次化的系统设计，各部分可以独立工作，提高了系统的可扩展性和可维护性。数据处理层负责对输入数据进行处理和分析，业务逻辑层基于数据处理的结果进行业务决策，用户界面层则提供友好的用户交互界面。3. 组件关系：用箭头表示各个组件之间的依赖关系，如前端与后端的交互、服务与数据存储的连接等。显示了一个完整的技术解决方案，包括数据处理层、业务逻辑层、用户界面层和数据存储层四个核心部分。2. 技术栈：列出项目中使用的主要技术和工具，如编程语言、框架、数据库等。

单体架构是早期软件开发的主流架构模式，但随着互联网应用的复杂性和规模的增加，单体架构的局限性逐渐显现出来。单体架构（Monolithic Architecture）是一种传统的软件架构模式，将整个应用程序作为一个单一的、统一的单元进行开发、部署和扩展。可扩展性差：由于所有功能模块都耦合在一起，当应用程序需要扩展时，必须扩展整个应用程序，而不仅仅是某个特定的模块。开发简单：由于整个应用程序是一个单一的实体，因此开发过程相对简单，开发人员可以更容易地理解和管理代码。

随着计算机科学和互联网的发展，分布式场景变得越来越常见，能否处理好分布式场景下的问题，成为衡量一个工程师是否合格的标准。本文我们介绍下分布式系统相关的理论知识，这些理论是我们理解和处理分布式问题的基础。

因为Nacos是支持windows和Linux系统的，且服务器操作系统一般都是Linux的，为了大家看完文章，可以按照步骤一步步把Nacos部署好，我们这里也采用Linux来部署Nacos。我们这里服务器地址是：192.168.3.102，Nacos采用Java开发的，我们需要先安装JDK。这里需要访问Nacos的中文官网获取Nacos的安装包：nacos-server-1.4.0.tar.gz。Nacos默认是后台启动，与Redis类似，我们可以利用tail命令查看启动日志。我们以后下篇文章接着聊。

前面我们介绍了微服务架构的各个组件以及各组件的职责，在Java领域中，Spring可以说是无人不知无人不晓的，我们现代的企业级应用和互联网应用，很大一部分都是构建在Spring生态体系上的，同样，实现微服务架构的SpringCloud也是在Spring基础上生根发芽的。

⑤克隆一台之前的虚拟机作为从（备）机，编辑从机的。是否生效，通过查看本机是否成功挂载虚拟。最后测试一下外网是否可以正常与。①首先创建一个对应的目录并下载。，只有当主机下线后，作为从机的。已经成功挂载，但另外一台机器。从上图中可以明显看见虚拟。

通过多台物理机器，组成一台逻辑上的庞大机器使用①高可用：集群内某个节点故障，可迅速将流量迁移至其他节点，解决了单点故障；②吞吐量：多台机器并行处理外部请求，可以为系统带来更强大的负载与吞吐能力；③拓展性：可根据业务的增长/萎靡，动态伸缩集群内的节点数量，系统更加灵活；④性价比：无需花费更高的价格升配机器，可使用多台价格、配置较低的机器构建。

通篇看完，大家会发现CAP理论并没有那么强大，它的作用更多局限于分布式存储领域，同时也并非整个分布式存储领域都会用到CAP思想，如今主流的分片式存储架构，就摒弃了传统的CAP模型。而BASE理论，则广泛运用于各类分布式系统，其中定义的三个概念，覆盖了分布式系统的大多数场景，比如微服务中的服务降级、熔断、限流机制，就是“基本可用”的一种体现。最后，在之前的文章中，我一直强调大家不要听风就是雨，学习技术时，务必保持审慎怀疑的态度！比如本文讨论的BASE理论，90%资料都在告诉你，它是CAP。

在分布式领域里，一致性成为了炙手可热的名词，缓存、数据库、消息中间件、文件系统、业务系统……，各类分布式场景中都有它的身影，因此，想要更好的理解分布式系统，必须要理解“一致性”这个概念。其实关于一致性的讲述，之前聊这两个分布式理论时也曾提及过，讲到CAP一致性是数据一致性，BASE一致性则是指状态一致性，不过当时讲的不够具体、不够体系化，更多是围绕着两个分布式理论在阐述，而本文就展开聊聊。

前面我们讲了一下 Ribbon 和 RestTemplate 实现服务端通信的方法，Ribbon 提供了客户端负载均衡，而 RestTemplate 则对 http 进行封装，简化了发送请求的流程，两者互相配合，构建了服务间的高可用通信。。为了便于理解，我们这里通过一个具体的案例来配合理解。

我们来认识一下微服务架构在Java体系中依托哪些组件实现的。相对于单体架构的简单粗暴，微服务的核心是将应用打散，形成多个独立提供的微服务，虽然从管理与逻辑上更符合业务需要。可以发现，以上的各个问题，不是针对某种语言或某种技术的，任何要构建微服务架构的企业都需要面对这些问题，要么公司内部逐个研究各个问题的解决办法，要么就将已有的多种技术整合形成整体解决方案。好在经过互联网行业的多年发展，业内对于上述问题基本都有了标准的解决方案，下图清晰的说明了微服务架构需要的标准组件。

尽管微服务架构有着高度独立的软件模块、单一的业务职责、可灵活调整的技术栈等优势，但也不能忽略它所带来的弊端。本篇文章，我们从网络、性能、运维、组织架构和集成测试五个方面来聊一下设计微服务架构需要考虑哪些问题，对设计有哪些挑战呢？

OK~，既然引入负载均衡技术可给我们带来如此巨大的好处，那么又有那些方案可供选择呢？主要有两种负载方案，，比较常用的硬件负载器有A10、F5等，但这些机器动辄大几万乃至几十万的成本，因此一般大型企业会采用该方案，如银行、国企、央企等。而成本有限，但依旧想做负载均衡的项目，那么可在软件层面实现，如典型的Nginx等，软件层的负载也是本文的重点，毕竟Boss。

实现了最基本的防盗链机制，最后只需要额外重启一下就好啦！当然，对于防盗链机制实现这块，也有专门的第三方模块。中就可获取该值，然后判断是否为本站的资源引用请求，如果不是则不允许访问。站是一点点去购买版权、签约作者的方式，从而积累了海量的壁纸素材，但。，心中必然不爽，那么此时又该如何屏蔽这类问题呢？有关，该字段主要描述了当前请求是从哪儿发出的，那么在。实现了更为完善的设计，感兴趣的小伙伴可以自行去看看。站的所有壁纸资源，继而提供给用户下载。根据上述中的内容配置后，就已经通过。的防盗链机制实现，跟上篇文章。

对于静态资源实现压缩传输，一方面可以节省带宽资源，第二方面也可以加快响应速度并提升系统整体吞吐。越小，那么自然传输速度会更快，同时也会更节省带宽，因此我们在部署项目时，也可以通过。①对于图片、视频类型的数据，会默认开启压缩机制，因此一般无需再次开启压缩。建立在动静分离的基础之上，如果一个静态资源的。从图中可以很明显看出，未开启压缩机制前访问时，中的基本压缩配置后，接下来可以在。在上述的压缩配置中，最后一个。文件而言，需要指定压缩类型为。的压缩配置后，可以在原本的。，当配置好压缩后再重启。

第一次访问时，因为还没有请求过资源，所以缓存中没有数据，因此没有命中缓存。第二、三次，依旧没有命中缓存，直至第四次时才显示命中，这是为什么呢？对于性能优化而言，缓存是一种能够大幅度提升性能的方案，因此几乎可以在各处都能看见缓存，如客户端缓存、代理缓存、服务器缓存等等，当缓存过多时，如果不及时清理会导致磁盘空间被“吃光”，因此我们需要一套完善的缓存清理机制去删除缓存，在之前的。的缓存则属于代理缓存的一种。相关的选项，开启后可以帮我们自动清理缓存，但遗憾的是：purger。中，又该如何配置代理缓存呢？

从上可以看出其逻辑并不复杂，仅是从响应中获取了。，因此请求会根据权重比均摊到每台机器，也就是。OK~，前提工作准备就绪后，再简单修改一下。至此，所有的前提工作准备就绪，紧接着再启动。，然后在该项目中，创建一个。服务启动时，将其端口号改为。因为配置了请求分发的权重，页面，并将该值携带返回。配置文件中，将端口号改为。资源的请求时，跳转前端。

在当前的互联网开发模式下，系统访问量日涨、并发暴增、线上瓶颈等各种性能问题纷涌而至，性能优化成为了现时代开发过程中炙手可热的名词，无论是在开发、面试过程中，性能优化都是一个常谈常新的话题”。Java语言作为企业应用中的“抗鼎者”，Java生态中也积攒了大量宝贵的性能优化经验。在应用系统中，性能优化其实可以从各个角度出发考虑，如本章则重点阐述Java中，JVM虚拟机相关的全面优化，如：内存、GC、即时编译、JVM参数配置等。

但如若文件上传/下载较为频繁，那么还是建议额外搭建文件服务器，并将上传/下载功能交由后端处理。上述配置仅是作为代理层需要配置的，因为最终客户端传输文件还是直接与后端进行交互，这里只是把作为网关层的。在某些业务场景中需要传输一些大文件，但大文件传输时往往都会会出现一些。，比如文件超出限制、文件传输过程中请求超时等，那么此时就可以在。中也可以作为文件服务器使用，但需要用到一个专门的第三方模块。，如果项目中文件上传的作用处不多，那么建议可以通过。配置调高一点，调到能够“容纳大文件”传输的程度。

上述的缓冲区参数，是基于每个请求分配的空间，而并不是所有请求的共享空间。当然，具体的参数值还需要根据业务去决定，要综合考虑机器的内存以及每个请求的平均数据大小。→服务端”，那么两个不同的连接速度不一致，就会影响用户的体验（比如浏览器的加载速度跟不上服务端的响应速度）。代理可暂存后端的响应，然后按需供给数据给客户端。最后提一嘴：使用缓冲也可以减少即时传输带来的带宽消耗。→服务端”，在这个过程中存在两个连接：“客户端→。速度，所以对于用户造成的体验感极差，因此在。的项目一般请求流程为：“客户端→。

既然有这么多请求属于静态的，这些资源大概率情况下，长时间也不会出现变动，那为何还要让这些请求到后端再处理呢？其实这个问题也并不难回答，当你搞懂了网站的本质后，自然就理解了动静分离的重要性。OK~，搞清楚动静分离的必要性之后，如何实现动静分离呢？②将项目中所有的静态资源全部拷贝到该目录下，而后将项目中的静态资源移除重新打包。服务的机器处理，那则代表着一个客户端请求淘宝首页，就会对后端服务器造成。最后提一嘴，也可以将静态资源上传到文件服务器中，然后。的请求数，而正常项目开发时，静态资源一般会放入到。

但如果后端是采用分布式架构开发的，有时候RPC调用也需要解决跨域问题，不然也同样会出现无法跨域请求的异常，因此可以在你的后端项目中，通过继承。相同的两个请求，则可以被看做是同源的，但如果其中任意一点存在不同，则代表是两个不同源的请求，同源策略会限制了不同源之间的资源交互。跨域问题在之前的单体架构开发中，其实是比较少见的问题，除非是需要接入第三方。，为了保证用户信息安全，防止恶意网站窃取数据，同源策略是必须的，否则。来实现有状态的信息记录，例如用户的身份/密码等，因此一旦。注解的方式实现接口之间的跨域配置。

的性能优化，主要就简单说说收益最高的几个优化项，在这块就不再展开叙述了，毕竟影响性能都有多方面原因导致的，比如网络、服务器硬件、操作系统、后端服务、程序自身、数据库服务等，对于性能调优比较感兴趣的可以参考之前。通常Nginx作为代理服务，负责分发客户端的请求，那么建议开启。到这里文章的篇幅较长了，最后再来聊一下关于。

难免会出现天灾人祸，比如系统异常、程序宕机、服务器断电、机房爆炸、地球毁灭....哈哈哈，夸张了。但实际生产环境中确实存在隐患问题，由于。宕机，最终就会导致整个系统不可用，这无疑对于用户的体验感是极差的，因此也得保障。在之前单体架构开发时，是一个用的较为频繁的高可用技术，比如。作为整个系统的网关层接入外部流量，所以一旦。线上如果采用单个节点的方式部署。机制，实现单节点应用的高可用。并不是只会员的意思，而是指。

为了确保通信安全，所以服务端需配置对应的数字证书，当项目使用。中也需要配置，接下来简单聊一下关于。的方式访问时，会自动将其改写为。随着越来越多的网站接入。的方式访问，并且当客户端使用。还不够，往往还需要监听。作为网关时，那么证书在。OK~，根据如上配置了。端口的请求，但在上篇。后，你的网站即可通过。

在上阶段，我们简单聊了下集群的基本知识，以及快速过了一下逻辑处理型集群的内容，下面重点来看看存储型集群，毕竟这块才是重头戏，集群的形态在其中有着多种多样的变化。逻辑处理型的应用，部署集群架构是为了解决单点故障、获得更高的吞吐量，集群内各节点之间没有依赖关系，同时遵循着“去中心化思想”，即多个节点里没有所谓的“老大”。

而有时候有些恶意攻击者或爬虫程序，被识别后需要禁止其再次访问网站，因此也需要实现。有时候往往有些需求，可能某些接口只能开放给对应的合作商，或者购买/接入。对于文件具体在哪儿导入，这个也并非随意的，如果要整站屏蔽/开放就在。文件中定然是不显示的，这种方式比较冗余，那么可以新建两个文件。中导入，如果只需要针对于某一系列接口屏蔽/开放。中导入，如果只需要一个域名下屏蔽/开放就在。添加到对应的文件后，可以再将这两个文件在。的合作伙伴，那么此时就需要实现类似于。黑/白名单实现方式，同时也可以通过。

说到架构，这个概念没有很清晰的范围划分，也没有一个标准的定义，每个人的理解可能都不一样。架构在百度百科中是这样定义的：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。我们可以理解为：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

当谈到人力资源管理时，电子人力资源（E-HR）系统已经成为现代企业不可或缺的组成部分。E-HR系统的设计与实践对于提高组织的人力资源管理效率和员工体验至关重要。本文将探讨E-HR应用架构的设计与实践，以及如何借助信息技术优化人力资源管理。