架构

来源： B 站 亿级流量电商详情页系统实战（第二版） 电商网站详情页架构： P3 ：架构 1 ：页面静态化架构； 小电商，静态页面少 Velocity/FreeMarker/Thymeleaf 模板 模板 + 数据 = 》最终的页面 如果模板或数据有变更，则需要重新渲染生成页面 html- 》推送 nginx P4 ：大型网站详情页架构 P5: 支撑高可用、高可靠、备份恢复 Redis 重要性 商品详情页的缓存架构： redis 架构： 1 ）高并发、高可用：海量数据，备份，随时可以恢复，缓存架构如果支撑这些， 首先， Redis 架构支撑：每秒几十万访问 QPS ， 99.99% 高可用， TB 级海量数据，备份和恢复，缓存架构就成功一半了。 最简单模式：存取 Redis 1 ）解决各种各样高并发场景下缓存面临的难题，缓存架构中不断引入各种解决方案和技术，解决高并发问题。 2 ）解决各种各样缓存架构本身面临的高可用问题，缓存架构中引入各种解决方案和技术，解决高可用问题。 P6: 指导虚拟机搭建 4 个节点 CentOS 集群 VirtualBox +CentOS6.5 内存 1G ，网卡选择桥接， 1 、配置网络 // 红色是 VI 的操作，紧随其后是具体命令 ; 先通过 DHCP 动态分配 IP ，然后将分配 IP （ ifconfig 查询结果）通过 static

一、概念 docker是开源容器引擎，基于cgroup,namespace,unionFS等技术实现，对应用进行封装的虚拟化技术 什么是cgroup？ 对系统资源限制，创建容器的过程其实就是在创建进程，对资源的分配和维护使用cgroup来管理，包括cpu，内存，io等? 什么是namespace? 创建容器时，对容器来说就是一个全新的系统，容器内的文件系统要和宿主机文件系统隔离，网络空间隔离，用户权限隔离，这些隔离操作都是有namespace 来管理完成的 什么是unionFS? 联合文件系统，简单理解就是多个目录结构合并成一个，而各个目录结构本身物理位置并没有变化。 二、架构 1.C/S架构 组件: docker cli: docker客户端，用来管理docker，向docker发送指令的工具 docker engine: 拉取推送镜像，对容器操作相关的api的最上层封装，直接面向client image repository: 注册中信，存储镜像的地方 Containerd: 是一个守护进程，负责管理shim,向docker engine提供接口,使用UnixSocket通信，协议是grpc shim: 负责管理单个容器，启动一个容器，就会启动一个shim进程, containerd管理所有容器 runC: 运行一个容器。是基于OCI标准的一个容器技术实现

1 聚合器微服务设计模式 这是一种最常用也最简单的设计模式，如下图所示： 聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。 2 链式微服务设计模式 这种模式在接收到请求后会产生一个经过合并的响应，如下图所示： 在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。 3 分支微服务设计模式 这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示： 4 代理微服务设计模式 这是聚合器模式的一个变种，如下图所示： 在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。 5 异步消息传递微服务设计模式 虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示： 6 数据共享微服务设计模式

美国环境保护署（EPA）报告的一组有趣的统计数据就证明了其好处。EPA 研究服务器和数据中心的能源效率时发现，实际上服务器只有 5% 的时间是在工作的。在其他时间，服务器都处于 “休眠” 状态。 底层硬件--->操作系统--->VMware和本机其他的APP--->运行不同的操作系统。 虚拟化是一个广义的术语，在计算机方面通常是指计算元件在虚拟的基础上而不是真实的基础上运行。虚拟化技术可以扩大硬件的容量，简化软件的重新配置过程。CPU的虚拟化技术可以单CPU模拟多CPU并行，允许一个平台同时运行多个操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。 虚拟化前 每台主机一个操作系统 软件硬件紧密地结合 在同一主机上运行多个应用程序通常会遭遇沖突 系统的资源利用率低 硬件成本高昂而且不够灵活 虚拟化后 打破了操作系统和硬件的互相依赖 通过封装到到虚拟机的技术, 管理操作系统和应用程序为单一的个体 強大的安全和故障隔离 虚拟机是独立于硬件的, 它们能在任何硬件上运行（有些虚拟化必须运行在他更改过的系统上的） 虚拟化定义：让应用程序运行在不同的空间内，这些空间彼此独立集合，大提升服务器的使用效率。 虚拟化分类 全虚拟化技术、半虚拟化技术/准虚拟化技术 全虚拟化技术 完全虚拟化技术又叫硬件辅助虚拟化技术，最初所使用的虚拟化技术就是全虚拟化（Full

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 概述 1.1 神龙架构的特点 阿里云官方文档对于神龙架构的描述如下： 保留了普通云服务器的资源弹性，并因嵌套虚拟化技术让弹性裸金属服务器保留了物理机的体验。 1.2 理解上的难点 同时拥有云服务器的资源弹性和保留了物理机体验的特点容易让用户在需要深入了解神龙架构时产生一个疑问：神龙架构到底是虚的还是实的，如果虚实融合又怎么来理解什么是虚实融合？通过什么手段做到的？ 1.3 本文重点说明的问题 结合以上神龙架构的特点和理解上的难点，本文详细的对于神龙架构进行研究分析，说明神龙架构是如何做到同时拥有云服务器的资源弹性和保留了物理机体验的目标的。 2 为什么需要发明神龙架构 2.1 以搬砖为例说明虚拟化技术的特点 把物理机变成虚拟机的这个技术，就是“虚拟化”。比如我家里装修有100块砖需要搬运，邻居家也在装修同样有100块砖需要搬运，我们各请了50个搬运工，当工人到达时发现邻居家的主人在睡觉，因此他家的50个工人只能等他睡醒再搬砖，我家请的50个工人则可以直接帮我开始搬砖，情况如下图所示： 正好两家的工人来自于同一个公司于是包工头过来看了一下，发现邻居家的工人在空闲状态觉得效率很低。于是决定既然邻居家的工人目前空闲于是一起来帮我家搬砖。和我商量费用并不增加，工人增加50个，我自然非常开心，觉得多给了我家50个工人

分布式RPC框架Apache Dubbo 1. 软件架构的演进过程 软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程，下面我们分别了解一下这几个架构。 1.1 单体架构 架构说明： ​ 全部功能集中在一个项目内（All in one）。 架构优点： ​ 架构简单，前期开发成本低、开发周期短，适合小型项目。 架构缺点： ​ 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。 ​ 技术栈受限，只能使用一种语言开发。 ​ 系统性能扩展只能通过扩展集群节点，成本高。 1.2 垂直架构 架构说明： ​ 按照业务进行切割，形成小的单体项目。 架构优点： ​ 技术栈可扩展（不同的系统可以用不同的编程语言编写）。 架构缺点： ​ 功能集中在一个项目中，不利于开发、扩展、维护。 ​ 系统扩张只能通过集群的方式。 ​ 项目之间功能冗余、数据冗余、耦合性强。 1.3 SOA架构 SOA全称为Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。 站在功能的角度，把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。 架构说明： ​

mybatis目录： Jdbc编程 mybatis架构图 mybatis入门程序 mybatis开发dao方法 4.1 原始dao开发方法 4.2 mapper代理开发方法 SqlMapConfig.xml配置文件 输入映射与输出映射 动态Sql 高级映射 来源： CSDN 作者： limts 链接： https://blog.csdn.net/qq_39779025/article/details/103463561

当下，Spark已经在国内得到了广泛的认可和支持：2014年，Spark Summit China在北京召开，场面火爆；同年，Spark Meetup在北京、上海、深圳和杭州四个城市举办，其中仅北京就成功举办了5次，内容更涵盖Spark Core、Spark Streaming、Spark MLlib、Spark SQL等众多领域。而作为较早关注和引入Spark的移动互联网大数据综合服务公司，TalkingData也积极地参与到国内Spark社区的各种活动，并多次在Meetup中分享公司的Spark使用经验。本文则主要介绍TalkingData在大数据平台建设过程中，逐渐引入Spark，并且以Hadoop YARN和Spark为基础来构建移动大数据平台的过程。 初识Spark 作为一家在移动互联网大数据领域创业的公司，时刻关注大数据技术领域的发展和进步是公司技术团队必做的功课。而在整理Strata 2013公开的讲义时，一篇主题为《An Introduction on the Berkeley Data Analytics Stack_BDAS_Featuring Spark,Spark Streaming,and Shark》的教程引起了整个技术团队的关注和讨论，其中Spark基于内存的RDD模型、对机器学习算法的支持

1-单体应用架构 优点:开发简单,适用于小型应用 缺点:不易拓展,维护,代码耦合 2-垂直应用架构 优点:解决高并发问题,针对不同的模块优化,方便水平扩展,容错 缺点:系统间相互独立,重复开发工作 3-分布式SOA架构 优点: 抽取公共的功能为服务,提高开发效率 对不同的服务进行集群化部署解决系统压力 基于ESB/Dubbo减少系统耦合 缺点: 抽取服务的粒度较大 服务提供方与调用方借口耦合度较高 SOA:面向服务的架构.可以根据需求通过网络对松耦合的粗粒度应用组件(服务)进行分布式部署,组合和使用.一个服务通常以独立的形式存在于操作系统进程中. 特点:分布式,可重用,扩展灵活,松耦合 4-微服务架构 优点: 通过服务的原子化拆分,以及微服务的独立打包,部署和升级,小团队的运营成本将缩短,运维成本也将大幅度下降 微服务遵循单一原则,微服务之间采用restful等轻量协议传输 缺点: 微服务过多,服务治理成本高,不利于系统维护 分布式系统开发的技术成本高(容错,分布式事务等) SOA与微服务的关系 SOA:面向服务的架构,它是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的功能.一个服务通常以独立的形式存在于操作系统进程中.各个服务之间通过网络调用. 微服务架构:强调的重点是业务需要彻底的组件和服务化.原有的单个业务系统会拆分成多个可独立开发,设计,运行的小应用

来源： CSDN 作者： apriaaaa 链接： https://blog.csdn.net/apriaaaa/article/details/103555438