架构

GPU架构 SM（Streaming Multiprocessors）是GPU架构中非常重要的部分，GPU硬件的并行性就是由SM决定的。 以Fermi架构为例，其包含以下主要组成部分： CUDA cores Shared Memory/L1Cache Register File Load/Store Units Special Function Units Warp Scheduler GPU中每个SM都设计成支持数以百计的线程并行执行，并且每个GPU都包含了很多的SM，所以GPU支持成百上千的线程并行执行，当一个kernel启动后，thread会被分配到这些SM中执行。大量的thread可能会被分配到不同的SM，但是同一个block中的thread必然在同一个SM中并行执行。 CUDA采用Single Instruction Multiple Thread（SIMT）的架构来管理和执行thread，这些thread以32个为单位组成一个单元，称作warps。warp中所有线程并行的执行相同的指令。每个thread拥有它自己的instruction address counter和状态寄存器，并且用该线程自己的数据执行指令。 SIMT和SIMD（Single Instruction, Multiple Data）类似，SIMT应该算是SIMD的升级版，更灵活，但效率略低

出自一篇看过的好文章，挖坑 来源： https://www.cnblogs.com/TeaPolyphenols/p/11330228.html

Nginx 是一个免费的，开源的，高性能的 HTTP 服务器和反向代理，以及 IMAP / POP3 代理服务器。Nginx 以其高性能，稳定性，丰富的功能，简单的配置和低资源消耗而闻名。 Nginx 的整体架构 Nginx 里有一个 master 进程和多个 worker 进程。master 进程并不处理网络请求，主要负责调度工作进程：加载配置、启动工作进程及非停升级。worker 进程负责处理网络请求与响应。 master进程主要用来管理worker进程，具体包括如下4个主要功能： 接收来自外界的信号。 向各worker进程发送信号。 监控woker进程的运行状态。 当woker进程退出后（异常情况下），会自动重新启动新的woker进程。 woker进程主要用来处理基本的网络事件： 多个worker进程之间是对等且相互独立的，他们同等竞争来自客户端的请求。 一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致。同时，nginx为了更好的利用多核特性，具有cpu绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效。 Ngnix 是如何实现高性能的？ 事件驱动模型 基于异步及非阻塞的事件驱动模型，可以说是 Nginx

2020/01/29, ASP.NET Core 3.1, VS2019 摘要：基于ASP.NET Core 3.1 WebApi搭建后端多层网站架构【7-编写角色业务的增删改查】 编写最简单的增删改业务，涉及到DI依赖注入的使用、AutoMapper的使用、工作单元与仓储的使用、雪花Id的生成 文章目录 此分支项目代码 本章节介绍了编写最简单的增删改查业务，涉及到DI依赖注入的使用、AutoMapper的使用、工作单元与仓储的使用 来源： https://www.cnblogs.com/kasnti/p/12241973.html

在 微服务的基建工作 中提到过，在云原生、微服务时代，如果还是手动修改服务地址，是几乎不可完成的工作，需要一种机制完成自动上报和获取服务地址的支撑组件，可以保障服务的快速上线和下线，这就是服务注册/发现组件。 为了表述方便，从系统规模定义几个阶段： 巨型应用架构时期：很多应用都是一个巨型服务，一个应用包含所有功能，部署在小型机和大型机上，或者直接部署在物理服务器上。 单体架构时期：应用体量缩小，服务增多，而且出现虚拟化技术，物理服务器被连接成虚拟化平台，应用部署在虚拟机中。 SOA架构时期：应用通用功能逐渐沉淀，业务应用借助沉淀的通用组件逐渐解耦，微服务的很多组件也是从这个时期开始成型。 微服务架构时期：这个时期承接模块化时期，甚至有一种说法是微服务只是SOA的一种特殊形式。系统进一步解耦，根据业务角色不同，应用以业务为分界，缩小为业务单元。 函数架构时期：应用进一步分割为函数，实现serverless架构，不需要具体的服务器概念，只需要执行函数的服务即可。目前来看，这个时期是比较理想的时期，因为不同人相互协作定义的函数，可能重复或者冲突，不利于架构的演进。 随着大家对在微服务或者函数架构中趟坑，很多人开始提出回归单体应用架构，这应该也是架构螺旋进步的一种方式。 在微服务中，还有一种角色是根据调用关系定义的： 客户端服务（简称客户端）：调用其他服务的实例 服务端服务（简称服务端）

从刚毕业到目前所在公司，差不多6年了，想想这六年里面，自己的能力和刚毕业比有了很大的提升，但是现在在什么能力上，我不知道，毕竟没有去过别的公司。最近也在思考自己未来，算是比较迷茫阶段。趁最近比较闲，顺便整理一下自己的职业路程 刚毕业阶段---工作一年半 　　刚毕业进入公司，公司的规模还算比较小的，那个时候觉得很开心，过的也比较充实，自己的任务就是写代码，读代码。在那个时候，自己的能力提升的非常快，毕竟在学校里面做的项目完全无法和公司的所在的项目类比。公司有一套自己的框架，在那个时候的我看来，写的非常不错。有很多比较好的编程规范：约定大于配置，强制树状依赖，多工程模型，但是也存在明显的问题，就是大量使用command 模式以及弱参数类型，导致接口上无法很直观定义入参和出参。那个时候第一次接触到正式项目流程，典型的瀑布式模型。这个阶段自己主要的精力就是学习公司的业务，阅读公司的框架的源代码，知道了很apache 开源项目，也是这个时候，能够熟练的使用一般的设计模式。那个时候公司的规模也比较小，经常也会写一下底层的工具类。架构也比较简单，没有所谓的分布式架构，基本上所有的业务逻辑在一个系统里面全部可以找到，排查问题也非常简单。 个人觉得，在这个阶段，是最适合学习的，尤其是自己的编码技能，也是在这个时候最容易提升的。刚毕业出来的时候，人还有一种拼搏的精神，这个时候相对来说各方面压力比较少

typora-copy-images-to: img 01 系统架构的演变 随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此也不断的演 进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google 带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安逸得过且过？ 其实生活不止眼前的苟且，还有诗和远方。所以我们今天就回顾历史，看一看系统架构演变的历程；把握现在，学习 现在最火的技术架构；展望未来，争取成为一名优秀的Java工程师。 1.集中式架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 优点： 系统开发速度快 维护成本低 适用于并发要求较低的系统 缺点： 代码耦合度高，后期维护困难 无法针对不同模块进行针对性优化 无法水平扩展 单点容错率低，并发能力差 2.垂直拆分 当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆 分： 优点： 系统拆分实现了流量分担，解决了并发问题 可以针对不同模块进行优化 方便水平扩展，负载均衡，容错率提高 缺点： 系统间相互独立，会有很多重复开发工作，影响开发效率 3.分布式服务 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来

互联网架构实践心得：浅谈高并发架构设计的16招 概览 标题中的高并发架构设计是指设计一套比较合适的架构来应对请求、并发量很大的系统，使系统的稳定性、响应时间符合预期并且能在极端的情况下自动调整为相对合理的服务水平。一般而言我们很难用通用的架构设计的手段来解决所有问题，在处理高并发架构的时候也需要根据系统的业务形态有针对性设计架构方案，本文只是列出了大概可以想到一些点，在设计各种方案的时候无非是拿着这些点组合考虑和应用。 有很多高并发架构相关的文章都是在介绍具体的技术点，本文尝试从根源来总结一些基本的方法，然后再引申出具体的实现方式或例子。下面是本文会介绍的16个方面的大纲： 减少请求数量 既然请求量大，那么第一个方面可以考虑是否可以让请求量不那么大，或者说至少进入我们业务系统的量不这么大。除了下面提到的两点，我们还可以从业务的角度考虑一下，如果这是一个限时活动，那么我们的活动受众群体是否需要是所有用户，如果不是的话是否就可以通过减少受众减少并发；如果需要群发推送让用户来参与非秒杀类活动是否要考虑错时安批推送，避免因为推送引起的人为大并发等等，在技术手段接入之前先看看运营和产品手段能否减少不必要的大流量。 合并请求 每一个独立的网络请求都是开销，我们可以通过合并动态静态的请求来减少请求数量。现在的Web前端应用基本都会在构件打包阶段对脚本、CSS进行压缩合并等预处理。

前端 VUE 接入层 DNS：阿里云　负载均衡：lvs+nginx/SLB/ELB 逻辑层 Java、Ｃ、Ｃ++、PHP、C# 存储层 MySQL/Redis 消息中间件 nsq 代码管理 gitlab 持续集成 jenkins 项目管理 redmind 名字服务 qconf zk 日志系统 elk 监控系统 promethues 配置系统 apollo 配置中心 发布系统 walle+jenkins+Gitlab 跳板机 jumpserver 机器管理 ansible 来源： https://www.cnblogs.com/wanwei2018/p/12238361.html

Zabbix简介 Zabbix是一个企业级的开源分布式监控解决方案，由C语言编写而成的底层架构（server端和agent端），由一个国外的团队持续维护更新，软件可以自由下载使用，运作团队靠提供收费的技术支持赢利。 zabbix是一款基于web页面的、开源的、企业级的，可以分布式部署的监控软件。 官方网站：http://www.zabbix.com Zabbix通过C/S模式采集数据，通过B/S模式在web端展示和配置。 被监控端：主机通过安装agent方式采集数据，网络设备通过SNMP方式采集数据 Server端：通过收集SNMP和agent发送的数据，写入MySQL数据库，再通过php+apache在web前端展示。 zabbix的作用 （1）监控windows和Linux主机上的软硬件状态。 （2）监控各网络设备，如路由器、交换机、防火墙、f5、打印机等。 （3）发送告警通知。 （4）通过web页面及图形展示监控数据。 zabbix的特性 （1）由server和agent程序协同工作，如果是分布式监控还需要proxy程序。 （2）监控方式站在agnet的角度分为主动监控(agent active)和被动监控(agent)。 主动监控： 当监控条目配置为agent active时，即为主动监控