架构

并发和并行 在真正开始聊本文的主题之前，我们先来回顾下两个老生常谈的概念：并发和并行。 并发 ：是指多个线程任务在同一个CPU上快速地轮换执行，由于切换的速度非常快，给人的感觉就是这些线程任务是在同时进行的，但其实并发只是一种逻辑上的同时进行； 并行 ：是指多个线程任务在不同CPU上同时进行，是真正意义上的同时执行。 下面贴上一张图来解释下这两个概念： 上图中的咖啡就可以看成是CPU，上面的只有一个咖啡机，相当于只有一个CPU。想喝咖啡的人只有等前面的人制作完咖啡才能制作自己的开发，也就是同一时间只能有一个人在制作咖啡，这是一种并发模式。下面的图中有两个咖啡机，相当于有两个CPU，同一时刻可以有两个人同时制作咖啡，是一种并行模式。 我们发现并行编程中，很重要的一个特点是系统具有多核CPU。要是系统是单核的，也就谈不上什么并行编程了。那么是什么原因导致了现代CPU架构都是多核架构？如果CPU架构都是单核的架构我们是不是就能不要研究什么并行编程了？ "摩尔定律"失效 上面章节中留下了一个问题：为什么现代CPU都是多核架构。为了回答这个问题，我们先来了解一个定律--摩尔定律。 1965年，英特尔联合创始人戈登·摩尔提出以自己名字命名的「摩尔定律」，意指集成电路上可容纳的元器件的数量每隔 18 至 24 个月就会增加一倍，性能也将提升一倍。 根据摩尔定律

（转载自 https://blog.csdn.net/weixin_37539378/article/details/79956760 ） 一、前言 ”前后端分离“已经成为互联网项目开发的业界标杆，通过Tomcat+Ngnix(也可以中间有个Node.js)，有效地进行解耦。并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。 前后端分离(解耦)的核心思想是：前端Html页面通过Ajax调用后端的RestFul API并使用Json数据进行交互。 注： 【在互联网架构中，web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。 应用服务器：一般指像tomcat，jetty，resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。】 一般只有Web服务器才能被外网访问，应用服务器只能内网访问。 二、为什么前后端分离 一般公司后端开发人员直接兼顾前端的工作，一边实现API接口，一边开发页面，两者互相切换着做，而且根据不同的url动态拼接页面，这也导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢，而且代码难以维护。而前后端分离的话，则可以很好的解决前后端分工不均的问题，将更多的交互逻辑分配给前端来处理

前言 本文来自 Prometheus官网手册 和 Prometheus简介 什么是prometheus？ Prometheus 是一个最初在SoundCloud上构建的开源系统监视和警报工具包。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发者和用户社区。 它现在是一个独立的开源项目，可以独立于任何公司进行维护。 为了强调这一点，并阐明项目的治理结构，Prometheus于2016年加入Cloud Native Computing Foundation，作为继Kubernetes之后的第二个托管项目。 特征 Prometheus的主要特征有： 多维度数据模型，由指标键值对标识的时间序列数据组成 PromQL，一种灵活的查询语言 不依赖分布式存储; 单个服务器节点是自治的 以HTTP方式，通过pull模型拉取时间序列数据 支持通过中间网关（pushgateway）推送时间序列数据 通过服务发现或者静态配置，来发现目标服务对象 支持多种多样的图表和界面展示 组件 Prometheus生态包括了很多组件，它们中的一些是可选的： Prometheus主服务器，用于抓取和存储时间序列数据 用于检测应用程序代码的客户端库 用于支持短声明周期的push网关 针对HAProxy，StatsD，Graphite等服务的特定exporters 警告管理器

6、使用反向代理和CDN加速网站响应 为了进一步加快网站的访问速度，可以考虑使用CDN和反向代理。CDN部署在网络提供商的机房，当用户访问时，可以从距离用户最近的网络提供商机房获取数据。反向代理部署在网站自己的中心机房，当用户请求到达机房时，优先访问的服务器是反向代理服务器，如果反向代理中缓存了用户请求的资源，那么就直接返回给用户，加快了响应的速度，也减轻了后端负载的压力。CDN与反向代理的基本原理都是缓存。 这一阶段涉及到的知识体系： 需要了解CDN和反向代理相关的知识 | 7、数据库的分库分表（垂直/水平拆分）及分布式文件系统 我们的网站演进到现在，用户、商品、交易的数据都还在同一个数据库中。尽管采取了增加缓存，读写分离的方式，但随着数据库的压力继续增加，数据库的瓶颈越来越突出，此时，我们可以采用分库分表两种方法进行解决。 分库： 又叫垂直拆分 ，就是把数据库中不同的业务数据拆分到不同的数据库中，结合现在的例子，就是把用户、商品、交易的数据分开。优点：解决了原来把所有业务放在一个数据库中的压力问题，可以根据业务的特点进行更多的优化。缺点：需要维护多个数据库。 分库所遇到的问题： 1）需要考虑原来跨业务的事务；2）跨数据库的join 解决方案： 在应用层尽量避免跨数据库的事物，如果非要跨数据库，尽量在代码中控制。我们可以通过第三方应用来解决，如上面提到的mycat

目录 微服务架构攀登之路（一）之微服务初识 微服务架构攀登之路（二）之RPC 微服务架构攀登之路（三）之gRPC入门 微服务架构攀登之路（四）之使用gRPC构建微服务 微服务架构攀登之路（五）之Go-micro入门 来源： https://www.cnblogs.com/zhangyafei/p/11933221.html

1. go-micro 简介 ⚫ Go Micro 是一个插件化的基础框架，基于此可以构建微服务，Micro 的设计哲学是可插拔的插件化架构 ⚫ 在架构之外，它默认实现了 consul 作为服务发现（2019 年源码修改了默认使用mdns），通过 http 进行通信，通过 protobuf 和 json 进行编解码 2. go-micro 的主要功能 ⚫ 服务发现：自动服务注册和名称解析。服务发现是微服务开发的核心。当服务 A需要与服务 B 通话时，它需要该服务的位置。默认发现机制是多播 DNS（mdns），一种零配置系统。您可以选择使用 SWIM 协议为 p2p 网络设置八卦，或者为弹性云原生设置设置 consul ⚫ 负载均衡：基于服务发现构建的客户端负载均衡。一旦我们获得了服务的任意数量实例的地址，我们现在需要一种方法来决定要路由到哪个节点。我们使用随机散列负载均衡来提供跨服务的均匀分布，并在出现问题时重试不同的节点 ⚫ 消息编码：基于内容类型的动态消息编码。客户端和服务器将使用编解码器和内容类型为您无缝编码和解码 Go 类型。可以编码任何种类的消息并从不同的客户端发送。客户端和服务器默认处理此问题。这包括默认的protobuf 和 json ⚫ 请求/响应：基于 RPC 的请求/响应，支持双向流。我们提供了同步通信的抽象。对服务的请求将自动解决，负载平衡，拨号和流式传输

　　　　 0、维和度量 　　　　事实表Fact Table： 　　　　　　　　事实表里面主要包含两方面的信息：维和度量 　　　　　　　　事实表中的维：关联到维表的键，并不记录具体信息； 　　　　　　　　事实表中度量：一般都会记录事件的相应数值，比如产品的实付金额等 　　　　维度表Lookup Table： 　　　　　　　　Lookup Table包含对事实表的某些列进行扩充说明的字段 2、olap 　　　　下钻（Drill-down）：在维的不同层次间的变化，从上层降到下一层，比如通过对2016年第二季度的总销售数据进行钻取来查看2016年第二季度4、5、6每个月的消费数据 　　　　上卷（Roll-up）： 钻取的逆操作，即从细粒度数据向更高汇总层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据 　　　　切片（Slice）： 选择维中特定的值进行分析，比如只选择电子产品的销售数据 　　　　切块（Dice）： 选择维中特定区间的数据或者某批特定值进行分析，比如选择2016年第一季度到2016年第二季度的销售数据 　　　　旋转（Pivot）： 即维的位置的互换，就像是二维表的行列转换，如图2-3中通过旋转实现产品维和地域维的互换。 3、Apache Kylin 　　　　Apache Kylin是一个开源的分布式分析引擎！中文名麒麟

一、软件架构的定义： 1、软件架构是一个系统的草图； 2、软件架构描述的对象是直接构成系统的抽象组件； 3、各个组件之间的连接则明确描述组件之间的通信； 4、在实现阶段，这些抽象组件被细化为实际组件（具体某个类或对象）； 5、在面向对象中，组件之间的连接通常用接口实现。 二、架构师可细分为三类： 1、系统架构师：服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等； 2、应用架构师：理解业务、梳理模型、设计模式、接口设计、数据交互等； 3、业务架构师：业务领域专家、行业专家、产品咨询师、资深顾问（以上两者结合）。 三、常见软件架构分类： 1、分层架构 2、事件驱动架构 3、微核架构 4、微服务架构 5、云架构 来源： https://www.cnblogs.com/citrus/p/11929376.html

1.MySQl主从复制 原理 ：将主服务器的binlog日志复制到从服务器上执行一遍，达到主从数据的一致状态。 过程 ：从库开启一个I/O线程，向主库请求Binlog日志。主节点开启一个binlog dump线程，检查自己的二进制日志，并发送给从节点；从库将接收到的数据保存到中继日志（Relay log）中，另外开启一个SQL线程，把Relay中的操作在自身机器上执行一遍 优点 ： 作为备用数据库，并且不影响业务 可做读写分离，一般是一个写库，一个或多个读库，分布在不同的服务器上，充分发挥服务器和数据库的性能，但要保证数据的一致性 2.主从复制的日志格式 这里的日志格式就是指二进制日志的三种格式：基于语句statement的复制、基于行row的复制、基于语句和行（mix）的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题 show variables like ‘%binlog%format%’; #查看当前使用的binlog的格式 set binlog_format = ‘row’; #设置格式，这种方法只在当前session生效 set global binlog_format = ‘row’; #在全局下设置binlog格式，会影响所有的Session 3.复制架构 3.1、一主多从架构 在主库的请求压力非常大时

程序员，真有必要了解架构吗？ 在解答这个疑惑之前，我们先来看一则故事：旅行者路过某个工地，建筑工人们都在忙碌。出于好奇，旅行者问第一个人在干什么，那人头也没抬地回答道：我在搬砖。旅行者问第二个人在干什么，这个匆匆抬起头认真地说：我在砌墙。旅行者问第三个人在干什么，那个人脸上充满了光彩，很自豪地说：我在建造圣索菲亚大教堂，将福音传播给更多人！ 有的人只关注眼下的“点”，有的人看到了延伸的“线”，还有人畅想出未来的“面”。就像在丛林中穿越，当你迷路找不到方向时，最好就是登上山顶或者爬上树冠，让自己有更宽广的视野，从而找到通往目的地的最佳路径。既要脚踏实地、低头赶路，也要抬头望天、畅想未来，正确的方向比速度更重要。接下来，我们来看看架构跟你的“点、线、面”关系。 一点 跟垒土坯房不同，建造摩天大楼离不开各式各样的设计图纸，构建复杂的应用系统也离不开架构设计。相信你所在的团队也配了架构角色，或由资深开发兼任，或由专职架构负责。不管你从事哪方面工作，包括产品、开发、测试、运维或项目等，你都要跟架构师打交道，例如：产品可研、概要设计、技术选型、详细设计、测试规划、部署规划、问题解决、招聘面试等等。如果对架构缺乏了解，那你就不清楚你跟架构师之间的协作界面，不知道架构师能给你提供哪些支持或帮助，不知道如何跟架构师高效地协作。如果只关心自己眼前的一亩三分地，那你很容易就滞留在“搬砖”层级。 二线