架构

1、CS、BS架构定义 　　CS（Client/Server）：客户端----服务器结构。C/S结构在技术上很成熟，它的主要特点是交互性强、具有安全的存取模式、网络通信量低、响应速度快、利于处理大量数据。因为客户端要负责绝大多数的业务逻辑和UI展示，又称为胖客户端。它充分利用两端硬件，将任务分配到Client 和Server两端，降低了系统的通讯开销。C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。 　　C/S 架构是一种典型的两层架构，其客户端包含一个或多个在用户的电脑上运行的程序，而服务器端有两种，一种是数据库服务器端，客户端通过数据库连接访问服务器端的数据；另一种是Socket服务器端，服务器端的程序通过Socket与客户端的程序通信。 　　BS（Browser/Server）：浏览器----服务器结构，是目前应用系统的发展方向。BS是伴随着Internet技术的兴起，对C/S架构的改进，为了区别于传统的C/S 模式，特意称为B/S模式。在这种结构下，通过W3浏览器来进入工作界面，极少部分事务逻辑在前端（Browser）实现，主要事务逻辑在服务器端（Server）实现，形成三层（3-tier）结构。这样使得客户端电脑负荷大大简化（因此被称为瘦客户端），减轻了系统维护、升级的支出成本

今天我们来总结一下架构设计流程，谈到架构设计我们先了解一下架构设计的原则 架构设计原则 架构设计主要可以归纳为三大原则 合适原则 简单原则 演化原则 合适原则 没那么多人，却想干那么多活，是失败的第一个主要原因 没有那么多积累，却想一步登天，是失败的第二个主要原因 没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因 简单原则 “复杂”在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，代表的是“问题”。 软件领域的复杂性体现在以下两个方面 结构的复杂性 结构复杂的系统几乎毫无例外地具备两个特点 ： 组成复杂系统的组件数量更多，同时这些 组件之间的关系也更加复杂 结构上的复杂性存在的第一个问题是 ： 组件越多，就越有可能其中某个组件出现故障，从 而导致系统故障 结构上的复杂性存在的第二个问题是：某个组件改动，会影响关联的所有组件，这些被影 响的组件同样会继续递归影响更多的组件 结构上的复杂性存在的第三个问题是 ： 定位一个复杂系统中的问题总是比简单系统更加困 难。首先是组件多，每个组件都有嫌疑，因此要逐一排查：其次组件间的关系复杂，有可能表 现故障的组件并不是真正问题的根源 逻辑复杂性 看到结构复杂性后，我们的第一反应可能就是“降低组件数量”，毕竟组件数量越少，系统 结构越简单。最简单的结构当然就是整个系统只有一个组件，即系统本身，所有的功能和逻辑

揭秘腾讯工蜂：企业级代码管理协作解决方案   互联网敏捷研发，离不开高效的代码管理系统。作为研发流程的基础环节，代码管理具备串联需求管理、持续集成、持续交付等上下游研发链路的作用，也承载着企业追求代码质量、鼓励代码复用等工程师文化的建设。腾讯拥有近3万研发人员，产品线漫长、业务种类繁多，不同的团队规模、技术栈和研发模式都对研发协作提出了不同的需求，也导致了代码库规模和研发流程参差不齐。同时编译系统、发布系统等需要检出所有代码，自动化程度越高，对代码库的访问压力就越大。提供安全稳定的代码服务，管理不同规模的代码仓库，支持各种类型的研发流程，是代码管理面临的三大挑战。基于行业状况及自身发展需要，腾讯选择了以Git为基础，在内部孵化了自研的Git系统——工蜂。   首先要解决服务端代码库存储扩容问题，因为单存储节点无法满足TB级增长的存储量，可考虑的有自定义数据分片和通用分布式文件存储两种方案。分布式存储的优点是对应用层屏蔽了底层存储结构，架构相对简单，但对IO密集型的代码管理应用来说，过于依赖分布式文件系统的IO性能，可移植性也不强。相反自定义数据分片可以自由控制分片策略，灵活均衡资源负载，另外在每个分片的底层存储上，也可以结合分布式存储，进一步扩展数据备份。工蜂选择了数据分片的方案，以仓库路径作为路由规则，并在应用层实现跨分片操作。数十万仓库分布在不同集群

Flink1.9重大改进和新功能 二、重构 Flink WebUI Flink社区讨论了现代化 Flink WebUI 的提案，决定采用 Angular 的最新稳定版来重构这个组件。从Angular 1.x 跃升到了 7.x 。重新设计的 UI 是 1.9.0 的默认UI，不过有一个按钮可以切换到旧版的WebUI。 点击上图所示按钮可切换至旧版Web UI： 新版更加漂亮，性能方面也表现更好。 注意：未来，新版UI不保证跟旧版 WebUI 的功能是对齐的，且待新版本稳定后将会完全移除旧版WebUI。 三、架构改动 F link老架构 及存在的问题 Flink设计理念与当前架构 Flink的设计理念如下图： 存在的问题 （1）从 Flink用户角度 1）开发的时候需要在两个底层API中进行选择 2）不同的语义、不同的connector支持、不同的错误恢复策略… 3）Table API也会受不同的底层API、不同的connector等问题的影响 （2）从 Flink开发者角度 1）不同的翻译流程，不同的算子实现、不同的Task执行… 2）代码难以复用 3）两条独立的技术栈需要更多人力功能开发变慢、性能提升变难，bug变多 F link 新架构 既然批是流的一个特例，是否可以。。。？一个大胆的想法(流批统一)： Blink本身就在做去DataSet的工作，在 Blink 捐赠给

OPD？这是什么玩意？google一下。忘记说了，最近google被封锁的厉害，那就百度一下吧。可惜，OPD找不出是什么。你今天你找不到是正常的，因为之前还没有OPD，而现在才开始有OPD这个东东。相信很多人听过敏捷个人了，这个词汇到现在已经很容易被搜索到了，敏捷个人创立以来，我一直未放弃对IT技术方法的实践和整理，而OPD就是我又要创建的一个东西，全称是Open Product Development。没错，是OPD，不是IPD，当然两者会有些关系，之所以我取Open，是因为我的IT产品开发方法大多数不是原唱，而是来自现有IT界中的已有方法，我只是类似在敏捷个人体系发展中占据的角色一样，我是一个集成者。OPD的工作无非就是把这些方法无缝的配合在一起，这个事情看起来考谱吗？ 靠不靠谱不能太随意下结论，现在重要的是先了解一下OPD是什么，看看是不是适合你和你的团队需要？如果需要的话，如何去学习、掌握并用在实际的工作中。 OPD是什么？ OPD （Open Product Development），它是由敏捷个人创始人周金根创立的另一个新方法体系，这一个来自实践的开放产品开发方法，它结合了精益创业Lean、企业架构TOGAF、架构描述语言ArchiMate、业务分析知识体系BABOK、敏捷开发Scrum、软件产品线、模型驱动架构设计OpenExpressApp。

课程目录: 01、课程介绍 02、背景说明 03、课程目标和主要内容 04、课程案例需求 05、课程补充说明 06、为何采用微服务架构？ 07、架构设计和技术栈选型 08、数据和接口模型设计:账户服务 09、数据和接口模型设计:业务服务 10、Dubbo、SpringCloud和Kubernetes该如何选型（上） 11、Dubbo、SpringCloud和Kubernetes该如何选型（中） 12、Dubbo、SpringCloud和Kubernetes该如何选型（下） 13、技术中台到底讲什么？ 14、Staffjoy项目结构组织 15、谷歌为何采用单体仓库（Mono、Repo）？ 16、微服务接口参数校验为何重要？ 17、如何实现统一异常处理？ 18、DTO和DMO为什么要互转？ 19、如何实现基于Feign的强类型接口？ 20、为什么框架层就要考虑分环境配置？ 21、异步处理为何要复制线程上下文信息？ 22、为你的接口添加Swagger文档 23、主流微服务框架概览 24、网关和BFF是如何演化出来的（上） 25、网关和BFF是如何演化出来的（下） 26、网关和反向代理是什么关系？ 27、网关需要分集群部署吗？ 28、如何设计一个最简网关？ 29、Faraday网关代码解析（上） 30、Faraday网关代码解析（下） 31、生产级网关需要考虑哪些环节？ 32

码农小光 的文章的记录 单机架构 第一次演进：Tomcat与数据库分开部署 第二次演进：引入本地缓存和分布式缓存 第三次演进：引入反向代理实现负载均衡 第四次演进：数据库读写分离 第五次演进：数据库按业务分库 第六次演进：把大表拆分为小表 第七次演进：使用LVS或F5来使多个Nginx负载均衡 第八次演进：通过DNS轮询实现机房间的负载均衡 第九次演进：引入NoSQL数据库和搜索引擎等技术 第十次演进：大应用拆分为小应用 第十一次演进：复用的功能抽离成微服务 第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异 第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理 第十四次演进：以云平台承载系统 总结: IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面； PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护； SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。 至此：以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案。但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论。 4、架构设计总结 1）架构的调整是否必须按照上述演变路径进行？ 不是的

从行业趋势看，Serverless 是云计算必经的一场革命 2019 年，Serverless 被 Gartner 称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路。 为此，我们策划了 Serverless 技术专栏 ，从基础概念入门，到前后台架构设计、应用拓展、最佳实践等多维度，揭开 Serverless 的面纱，带你走进无服务器的世界。 什么是 Serverless？ Serverless ，按中文翻译，称为「无服务器」。 这究竟是一种什么样的形态或产品呢？无服务器，就是真的没有服务器吗？ 其实，在行业内，目前对于 Serverless 有几种解读方法： 在某些场景可以解读为一种软件系统架构方法，通常称为 Serverless 架构 而在另一些情况下，又可以代表一种产品形态，称为 Serverless 产品 在说起 Serverless 架构时，Serverless 代表的是利用 Serverless 形态的产品实现的应用架构，这种架构完全依托于云厂商或云平台提供产品完成系统的组织及构建。在这种架构中，用户无需关注支撑应用服务运行的主机，而将关注点投入在系统架构，业务开发，业务支撑运维上。 而说起 Serverless 产品时，代表的是无需理解、管理服务器，按需使用

#CPU体系结构的种类特点及应用场合 一、ARM ARM架构，过去称作进阶精简指令集机器（Advanced RISC Machine，更早称作：Acorn RISC Machine），是一个32位精简指令集（RISC）处理器架构，其广泛地使用在许多嵌入式系统设计。 特点： 体积小、低功耗、低成本、高性能；支持 Thumb （ 16 位） /ARM （ 32 位）双指令集，能很好的兼容 8 位 /16 位器件；采用RISC体系结构，大量使用寄存器，指令执行速度更快；大多数数据操作都在寄存器中完成；寻址方式灵活简单，执行效率高；指令长度固定；对于不同系列的ARM有各自的特点。 应用领域： 工业控制领域：作为32的RISC架构，基于ARM核的微控制器芯片不但占据了高端微控制器市场的大部分市场份额，同时也逐渐向低端微控制器应用领域扩展。 网络应用：随着宽带技术的推广，采用ARM技术的ADSL芯片正逐步获得竞争优势。此外，ARM在语音及视频处理上进行了优化，并获得广泛支持，也对DSP的应用领域提出了挑战。 消费类电子产品：ARM技术在目前流行的数字音频播放器、数字机顶盒和游戏机中得到广泛采用。 成像和安全产品：现在流行的数码相机和打印机中绝大部分采用ARM技术。手机中的32位SIM智能卡也采用了ARM技术。 二、X86/Atom

来源： https://www.cnblogs.com/Unlimited-Rain/p/12370320.html