架构

最近学习了一些关于架构设计的知识想分享给大家。俗话说得好，不想当架构师的程序员不是好厨子。那么如何成为一名架构师呢？接下来就聊一聊我的一些想法。 什么是架构师 之前有同学问我，做了几年技术，应该转管理还是转架构师？对于这位同学，我给他的答案是，你要先踏踏实实做好现在的工作。因为就他提的问题来看，应该是刚入行不久或者是在校学生。 专心做技术的，都想做架构师。但架构师并不是说技术做时间长了可以转的。随着你的知识深度和广度的增加，在工作中会扮演更重要的角色，承担更大的责任，最终自然而然就会接触到架构设计的工作。 而架构师的主要工作，其实是利用架构设计知识以及丰富的工作经验，在设计架构时，结合实际情况，在不同的选项中做出取舍。 架构设计的真正目的？ 为什么要进行架构设计？因为架构设计很重要？可是为什么重要呢？似乎说不清楚。 因为可以提升开发效率吗？也不一定，因为只有简单的设计才会使开发效率更高。而架构设计出于多方面考虑，不得已会引入一些复杂度，因此架构设计并不一定能提升开发效率。 是为了大多数口中的“高可用”、“高性能”、“可扩展”吗？其实也不是。我们的系统可能并不一定需要这些。 那架构设计的真正目的是什么呢？我认为架构设计的真正目的是与系统复杂度做斗争。 系统复杂度的来源有： 高性能、高可用、可扩展性、低成本、安全、规模 。 前面我们聊到有些系统可能不需要高可用、高性能

一、k8s集群组成 1、k8s集群主要分为master、node、etcd集群 master　　//负责集群管理 node　　//负责计算，跑任务 etcd　　//k8s的元数据库 2、k8smaster组件 scheduler　　//调度器 apiserver　　//架构核心，接受客户请求 controller-manager　　//控制器 3、node组件 kubelet　　//负责完成apiserver下发的指令，完成用户的请求 kube-proxy　　//负责node网络 二、 来源： https://www.cnblogs.com/houjunjun437416/p/11862693.html

网络架构及其演变过程 一、单机架构 应用领域： 植物大战僵尸 office 二、CS架构 应用领域： QQ 大型网络游戏 计算机发展初期用户去取数据，直接就去主机拿，从这里开始就分出了客户端和服务端。 客户端：用户安装的软件； 服务端：统一管理数据库的主机中的软件就叫做服务端，再后来服务端不只是管理数据，外加处理业务逻辑。 2.1 CS架构要求 用户操作系统安装客户端；产商操作系统部署服务端 每个用户需要独立安装软件、服务端升级也要每个用户升级 2.2 面试题：数据放在服务端和客户端的利与弊？ 答： 服务端统一处理有更好的安全性和稳定性而且升级比较容易，不过服务器负担就增加了。 客户端将负担分配到每个用户，从而可以节约服务器资源，安全性和稳定性可能会有一定的问题，但是升级比较麻烦，每个安装的客户端程序都需要升级，另外为了节省网络资源，通过网络传输的数据应该尽量减少！ 三、BS架构 应用领域： 淘宝 京东 统一客户端即默认安装用户电脑中的浏览器，访问同种类的网站，具体业务的处理根据相应协议和标准提供通用的服务器程序，在不同的服务器处理。 3.1 两种BS架构 OSI主要用于教学（万恶的大学、绿本的计算机书），我们在编程的时候用的都是TCP/IP。 TCP/IP的对应关系，就像我们在淘宝购物，所在位置有的快递（网络接入层），告诉卖家地址（网络互联层）、快递送货（运输层）

一、获取token 认证( authentication ) 和授权 ( authorization )  授权中心 认证客户端配置 设置clientid scop 类型等 配置用户 让我们的安全配置生效 测试 获取 token 这里的username 和password 是clientid和密码前面配置的 成功返回 二、搭建资源服务器并且访问 1、让订单服务器知道自己是 Oauth 的资源服务器 2、 让订单服务知道自己是 order-server 资源服务器 3、在订单服务器上配置在哪里验证令牌，怎么验证 API 中怎么拿到token的用户名 测试 先得到token，然就访问 请求头前面加bearer 表示则是一个oauth2的验证 然后 空格+ token值 API 里想要拿到User信息 全部是true service 里返回的是什么 这里就是什么类型 user 但是我们令牌都是配置在内存的，需要放到数据库 执行sql 密码加密方式 DataSource 配置 使用数据库 来源： https://www.cnblogs.com/lyon91/p/11858146.html

工作机制 L（Linux）N（Nginx）M（Mysql）P（PHP）架构想必大家都知道，LNMP架构主要作用是让前端服务与后端存储以及后端的一下服务进行连接起来，来实现php程序的动态请求。 　　　而今天我们又在LNMP架构上面加一个Redis程序，而Redis在整个架构中起到了一个数据缓存的作用。 LNMP+Redis工作机制：当用户通过浏览器访问网站时，并使用账号密码进行登陆时，此时会向Redis发出查询请求，若Redis缓存中没有相关信息，则php会查询mysql数据库中的相关信息，然后将相关信息缓存在redis中；在下次此用户访问时，php无需再从mysql数据库中读取数据，直接从redis中读取缓存并将数据返回，这样就可以减少数据库的读取压力。 下面是简单的工作机制示意图 系统环境描述 Linux系统版本：我这里使用的是Ubuntu系统，大家可以选用不同的Linux版本 jia@uduntu:~$ lsb_release -a 　　　　No LSB modules are available. 　　　　Distributor ID: Ubuntu 　　　　Description: Ubuntu 19.10 　　　　Release: 19.10 　　　　Codename: eoan Nginx软件版本 　　nginx/1.16.1 (Ubuntu) PHP软件版本 　　

Zipkin基本概念 Span：基本工作单元，一次链路调用就会创建一个Span Trace：一组Span的集合，表示一条调用链路。举个例子：当前存在服务A调用服务B然后调用服务C，这个A->B->C的链路就是一条Trace，而每个服务例如B就是一个Span，如果在服务B中另起2个线程分别调用了D、E，那么D、E就是B的子Span Zipkin架构 先看一下架构图 其中左边部分代表了客户端分别为： InstrumentedClient：使用了Zipkin客户端工具的服务调用方 InstrumentedServer：使用了Zipkin客户端工具的服务提供方 Non-InstrumentedServer：未使用Trace工具的服务提供方，当然还可能存在未使用工具的调用方 总结：一个调用链路是贯穿InstrumentedClient->InstrumentedServer的，每经过一个服务都会以Span的形式通过Transport把经过自身的请求上报的Zipkin服务端中 右边线框内代表了Zipkin的服务端，其中各组件的功能如下： UI：提供web页面，用来展示Zipkin中的调用链和系统依赖关系等 Collector：对各个客户端暴露，负责接受调用数据，支持HTTP、MQ等 Storage：负责与各个存储适配后存储数据，支持内存，MySQL，ES等 API

1.概念 前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。 2.老的方式 1.产品经理/领导/客户提出需求 2.UI做出设计图 3.前端工程师做出html页面 4.后端工程师将html页面套成jsp页面(前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低) 5.集成出现问题 6.前端返工 7.后端返工 8.二次集成 9.集成成功 10.交付 3.新的方式 1.产品经理/领导/客户提出需求 2.UI做出设计图 3.前后端约定接口&数据&参数 4.前后端并行开发（无强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高） 5.前后端集成 6.前端页面调整 7.集成成功 8.交付 4.前端技术架构 架构描述：以Node.js为核心的Vue.js前端技术生态架构 来源： https://www.cnblogs.com/itzlg/p/11854232.html

我也要谈谈大型网站架构之系列（1）——纵观历史演变（上） 　　我们知道一个网站都是随着业务的发展，逐渐演变成几万服务器，几亿用户数的大型网站，经历了若干年，甚至上十年的 发展成为大型网站，然而真正亲身经历这个发展过程的人已经不多了，这种人也是拿着公司股票，赶都赶不走的人，所以正因 为很多人没有亲身经历过，所以对架构的演变没有深刻的了解，包括我自己在内，不过没吃过猪肉，也看过猪跑。。。 一：第一代架构 　　这年头创业大多都是从穷屌丝开始的，奔着 “快好省”的原则建立网站，将“应用程序”，“文件”，“数据库”通通放在一台服务 器上，匆匆的就走上了网站架构之路。 我们知道业务的发展对技术会有更高的要求，业务的创新会触动技术的创新，当业务逐渐发展起来的时候，最容易出现的问题就是 ”存储空间“和通用的”性能低下“，这个时候就需要做到”应用程序“和”数据“的分离。 二：第二代架构 　 随着业务规模的扩大，需要将”应用程序“，”文件“，”数据库“进行分离，用更强大的cpu处理服务器来承载应用程序，记得在上一 家用的cpu就是16核，”文件“的话则需要更大的磁盘空间的服务器，”数据库“的话需要更大的磁盘和超大内存的服务器，我们知道 sqlserver还是很吃内存的，记得用过最大的是120g的内存。 随着业务规模不断扩大，访问人数逐渐增多，我们也开心了，起码挣到钱了

阿里巴巴服务化架构演进 单一应用架构 All In One 整个网站几个应用 前台 web + 后台 ops + tasks 业务 web + service/dao 各自开发 一起集成发布 技术战：Webx、Spring Ibatis、Jboss、Oracle 存在的问题：合并时经常代码冲突、发布相互制约效率低下、应用代码庞大臃肿维护困难。 垂直应用架构 按应用拆分 Service / DAO / Impl 都以二方库 jar 包的形式提供出去 代码拆分，独立部署，流程隔离，技术栈没有太大变化 应用相互之间直接依赖二方库 问题： 升级困难，要全网推动 数据库连接池压力大 分布式服务架构 API 与实现分离 使用 RPC 进行通信，服务端升级方便 各种服务中心出现，会员中心，商品中心，交易中心等 技术栈： Ali-tomcat Pandora Dubbo HSF 存在的问题： 依赖冲突 中间件升级困难 应用配置服务 应用开发效率低下 微服务架构 拥抱微服务，提升开发体验和效率 应用更轻量、开发更简单 配置 编码 开发 调试 部署 技术栈： Pandora Boot Spring Boot 容器隔离Pandora 为什么需要隔离？ Pandora的容器架构如下： Pandora 结构与部署形式： 与应用 tgz 包部署在一起 应用可单独升级 pandora.sar 应用容器识别

今天与大家分享下，Jedis连接池使用。先看一段JAVA 代码： JedisPoolConfig config = new JedisPoolConfig(); config.setMaxIdle(100); JedisPool pool = new JedisPool(config, "ip地址", 6379); return pool.getResource(); 这段代码是最简单连接redis的连接池代码，单机连接，存在单点故障。不过也看这个IP是否是VIP， redis可以做成HA模式。架构如下图： redis 两台服务器，通过专业的HA软件实现主从管理，对外通过VIP提供服务，但主机宕机，HA会切换到从机运行，同时改变从机的角色为： master.。 这种架构不适合做读写分离，只有一台机器ONLINE 状态。 Redis 分片架构，先看图。典型的分片架构如下图： 该架构适合做并发较高，访问量大，如果采用jedis连接，可以实现Hash 一致性数据分布。具体代码如下： JedisPoolConfig config = new JedisPoolConfig(); List<JedisShardInfo> shards = new ArrayList<JedisShardInfo>(); shards.add(new JedisShardInfo("10.20.15.236"