架构

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

架构者，骨骼也。架构好，则生命力强，可扩展性强，可维护性高。正所谓根深苗正。 一个应用的底层架构不扎实，不精简，不彻底，那么随着时间的推移，应用的扩展性将变得愈发困难，可读性会越来越差，健壮性也会因此受到影响。 那么，什么样的架构才算是优秀的架构呢？行业里有没有规范呢？答案是肯定的，有。我非常喜欢 “规范” 这两个字。规范不像法律，规范更像是道德。也就是说，“规范”不具有强制性。不守规范就像是得了慢性病，这种诟病随着时间的推移才会越来越清晰地显现出来。 来源： https://www.cnblogs.com/youknownothing/p/11004469.html

关于微架构方面，只能作为一个发烧友介绍，出于兴趣爱好平常多看一些书籍。希望电子技术专业的童靴们，如果想学习设计集成电路微架构的话，一定好好学习！！！ 在此我仅仅列举一些处理器通常采用的技术： 流水线技术、多发射技术、多核技术、超线程技术、超标量技术、缓存技术、分支预测技术、乱序执行技术、制作工艺等等！ 国内网站有关这方面的资源比较少，可以去维基百科试试。 来源： CSDN 作者： 嵌入式系统架构 链接： https://blog.csdn.net/weixin_46261723/article/details/104180155

目录 一、系统架构演变 1.集中式架构 2.垂直架构 3.分布式服务 4.SOA架构 5.微服务架构 6.微服务和SOA的区别 二、服务的调用方式 1.RCP 2.HTTP 3.两者的使用场景 三、SpringCloud的概念 四、微服务的场景 五、Eureka注册中心 六、Ribbon负载均衡 七、Hystrix延迟容错库 八、Feign 九、Zuul网关 一、系统架构演变 1.集中式架构 （1）集中式架构，是指由系统的所有业务单元，都集中部署到一台或者多台服务器组成的中心节点上 （2）图解 （3）优点 部署方便 （4）缺点 ①不能水平扩展：承载的并发量小 【注】水平扩展：同时增加多个服务器实现负载 垂直扩展：提高单台服务器的性能 ②代码耦合性强，不利于功能的扩展 （5）应用场景 小型项目，访问量比较低 2.垂直架构 （1）将系统的各个模块拆分，分别部署在不同的服务器 （2）图解 （3）优点 ①提高的并发：将不同的模块部署到不同的服务器，对访问量比较大的模块，进行集群增加服务器的操作，充分的节约服务器的成本 ②方便水平扩展，可以针对某个模块进行定向优化 （4）缺点 代码重复度高，不同模块之间的功能有重复 3.分布式服务 （1）垂直架构代码重复度高，维护困难，分布式将核心的业务模块抽离出来，互相调用 （2）图解 （3）优点 ①提高了代码的复用率 （4）缺点 ①系统调用关系复杂

单体架构-》SOA-》微服务： 1. 从三层到mvc单体架构（特点：用户少并发少，并发增加），便于管理在一个项目中，但项目越来越大满足不了需求过于臃肿、不能拓展（有些模块需要进行扩展有些无需扩展）、资源不能分离。 2.SOA和微服务都是架构思想，基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给系统提供服务，系统与服务之间采用webservice、rpc等方式进行通信，ESB企业服务总线作为项目与服务之间通信的桥梁。EAI是什么，各个系统间互联，相互传数据的解决方案，原来通过socket通讯方式，只能在同一平台上进行通讯。基于中间系统，为了能满足跨平台的通讯，出现了webserver松耦合的通讯方式，数据通过xml传输。ESB包含了EAI的功能， 简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。与API网关统一层面的东西，在微服务思想中叫API网关，SOA思想中是ESB，在之前是EAI。 3. 前端代码和后台得分离，将后台代码分布在多个服务器上，负载均衡，缓解并发压力。慢慢对于模块中不同的需求，某个模块需要更多的服务器有些或许对性能要求不高，从而产生了微服务化，将原有的业务拆成独立的工程， 独立部署，灵活扩展。微服务是以每一个独立组件（例如用户服务，商品服务

在目前流行的互联网架构中，对一个应用来说，Tomcat是首，SSM是中，JVM是尾，我们通常对于SSM是比较了解的，而忽略了首尾，而Tomcat在目前的网络编程中是举足轻重的，但是我们其实对Tomcat中很多原理性的东西不太了解，如果能够掌握Tomcat的原理，那么是非常有用的，比如： 如果我们能弄清楚Tomcat和Socket、Tcp之间的关系，我们就能明白Tomcat为什么会出现端口冲突。 如果我们能准确的知道Tomcat中部署一个项目的N种方式，那么就能在工作中更加得心应手。 Tomcat中热部署和热加载的区别是什么，到底是如何实现的，弄明白实现原理，能很大程度上提高Tomcat的运行效率。 Tomcat到底是如何处理一个请求的？这对于针对Tomcat的性能调优是必备的。 目前Spring Boot和Dubbo等框架中都是使用的内嵌Tomcat，那么一个内嵌的Tomcat到底是如何运行的？ Tomcat的架构设计其实非常优秀的，如果能明白Tomcat为什么要那么设计，那么对于Tomcat的原理和自己的架构设计思维都能有很大提升。 JSP虽然过时，但是它的底层实现原理和思路依然保存着，那么Tomcat中到底是如何实现JSP功能的？ 所以，对于Tomcat，正是因为足够强大和优秀才容易被我们忽视。工欲善其事必先利其器，如果我们能真正掌握Tomcat的底层原理，那么将会有很大收获。

Oracle发布《 面向大规模可伸缩网站基础设施的MySQL参考架构 》白皮书，针对将MySQL用作数据存储的不同类型和不同规模的网站给出了推荐的拓扑结构。 根据分别提供4类服务——用户和会话管理、电子商务、分析类应用 (多结构数据)和CMS（元数据）——的网站的规模和可用性要求（如下表所示），这份白皮书给出了4个参考架构。 请注意，这里给出的指导方针只是基本建议，实际应用中需要根据读写模式、负载平衡和所用的缓存机制等因素进行调整。 小型（Small）网站参考架构 这一参考架构可用于上述4类网站的所有小型实现。可以使用MySQL Replication来制作数据的副本以支持备份和分析。 中型（Medium）网站参考架构 在这种情况下，推荐针对不同类型的活动选择独立的基础设施，考虑每个MySQL服务器最多支持8个应用服务器，如果因伸缩性需求应用服务器数量增加，则添加更多的MySQL从服务器。 为满足会话管理网站和电子商务网站的高可用性要求，可以使用 Linux心跳（Heartbeat） 和半同步复制。CMS网站通常对读操作的向外扩展有更高要求，假定每个MySQL从服务器最多可以处理3000个并发用户，白皮书建议为每个MySQL主服务器添加20-30个从服务器。CMS系统可将数据保存在一个SAN中，或者保存在连接到该服务器的分布式设备中。

一、背景 1.1 应用系统的架构历史 1.2 什么是微服务？ 起源:微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 通信方式:每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。 微服务的常规定义:微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务。 把原来的一个完整的进程服务，拆分成两个或两个以上的进程服务，且互相之间存在调用关系，与原先单一的进程服务相比，就是“微服务”。（微服务是一个比较级的概念，而不是单一的概念） 1.3 微服务架构的优势 可扩展性:在增加业务功能时，单一应用架构需要在原先架构的代码基础上做比较大的调整，而微服务架构只需要增加新的微服务节点，并调整与之有关联的微服务节点即可。在增加业务响应能力时，单一架构需要进行整体扩容，而微服务架构仅需要扩容响应能力不足的微服务节点。 容错性:在系统发生故障时，单一应用架构需要进行整个系统的修复，涉及到代码的变更和应用的启停

1. STM32F4系列使用ARM架构的ARMV7-ME架构，属于Cotex-M4系列，支持浮点运算单元FPU和DSP指令。 2. 与ARM Cotex-A8是支持MMU的处理器相比，Cotex-M4不能支持带虚拟内存的操作系统比如Linux，但是M4支持MPU即内存保护单元，一般用于对UcosII系统代码的保护。另外，M4具备功耗更低的优势。 3. STM32最小系统包括： （1）供电电路 （2）复位 （3）时钟：外部晶振（2个） （4）Boot启动模式选择 （5）下载电路（串口/JTAG/SWD) （6）RTC电路 来源： CSDN 作者： 川渝小神丢 链接： https://blog.csdn.net/fengel_cs/article/details/104173149

1. 概述 本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径 2. 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时