架构

待补充 来源： https://www.cnblogs.com/du-z/p/11905586.html

这是敏捷开发一千零一问系列的第十篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 问题 总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？ 方案 之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。 方案1：开发人员全体参与架构设计 敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。 一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保不发生歧义，因此做架构的人和写代码的人在一定程度上融合一下，能大量减少不必要的架构设计，尤其是某些细节。 二方面，文档或设计本身不是工作产品，在上面投入太多的工作量，极有可能是浪费而非保障。 当然问题是：哪些人有能力做架构？ 这个问题如果换成：哪些人可以开一家新的世界500强企业？答案是“大学在校生”（IT界最近的世界500强多数都是在大学里边成立的）。所以同样是这些人，一样能做架构，只是看怎么做了。 方案2：用师徒团队搭建全民架构团队 如果没有专门的架构人员和编码人员，那么最好的结构就是师傅们做架构，同组的徒弟们将其实现为编码。 “这不也是分工吗？”是的

纯洁的微笑公众号文章：【12张手绘图】我搞懂了微服务架构！ 什么是微服务？ 微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。 每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。 另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。 可以使用不同的语言来编写服务，也可以使用不同的数据存储。 根据马丁.福勒的描述，我总结了以下几点： ①小服务 小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。 ②进程独立 每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整个服务。 ③通信 过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and dumb pipes。 这些 Endpoint 都是解耦的，完成一个业务通信调用串起这些 Micro Service

我们知道当前 云桌面 的厂家可以说是非常之多，同时他们采用的架构和实现模式也是有很多的，既有采用RDP架构的，同时也有采用VOI和IDV架构的，以及采用VDI架构的，而这些都被厂家和用户称为云桌面的，但是其实真正了解云计算和云桌面的人会知道，只有VDI才可以说是真正意义上的云桌面的，为什么这么说的呢？ 第一数据在云端，VDI架构的云桌面采用的是集中计算和集中存储管理的方式，即所有的数据和计算都在服务器上进行，而终端设备只作为一个链接的桥梁存在着，本地不进行数据存储和计算，同时用户在使用终端设备进行访问重要数据或者接入U盘等存储工具时都需要权限才可以进行的，这样的好处就是数据都在服务器上统一存储和运行，不仅方便管理和维护同时还能确保数据不落地，加强数据的安全性。 第二维护在云端，之所以说VDI才是真正意义上的云桌面除了它数据在云端之外，还有一个就是它的维护同样在云端就可以完成，由于数据和运算都在服务器上进行，本地终端不就行任何数据的存储和计算，所以终端用户所使用的的系统和软件这些的管理和维护都是通过服务器来完成，终端不需要管理和维护的，即使是有几百上千个的用户使用，一样只需在服务器就可以进行轻松的进行管理和维护。 第三办公在云端，相比于其他架构的云桌面，VDI它还有一个最大的特点就是办公在云端，所谓办公在云端，是指通过VDI可以实现随时随地的办公，也就是说用户不仅可以通过云终端、手机

（1）单块架构 网站开始建立时，用户少 , 网站架构都是用单体架构设计，共部署 3台服务器，1台应用，1台数据库，1台图片。 1、应用服务器上发布， 可能是把应用服务器上的 Tomcat给关掉，替换系统的代码war包，重新启动Tomcat。 2、数据库服务器，存全部核心数据。 3、网络文件系统（NFS） 作图片服务器，存网站全部图片。应用服务器上代码会连接以及操作数据库以及图片服务器。 如下图所示： 　　 但是这种纯单块系统架构下，有高可用问题存在，最大的问题就是应用服务器可能会故障，或者是数据库可能会故障 所以在这个时期，一般稍微预算充足一点的公司，都会做一个初步的高可用架构出来。 （ 2）初步的高可用架构 应用服务器而言，集群化部署，初期用户量少的情况下，一般就是部署两台应用服务器，前面会放一台服务器部署负载均衡设备，如说 LVS（Linux虚拟服务器），均匀把用户请求打到两台应用服务器上去。 如此时某台应用服务器故障了，还有另外一台应用服务器是可以使用的，这就避免了单点故障问题。如下图所示： 对于数据库服务器而言，此时一般也会使用主从架构，部署一台从库来从主库同步数据，这样一旦主库出现问题，可以迅速使用从库继续提供数据库服务，避免数据库故障导致整个系统都彻底故障不可用。如下图： （ 3）千万级用户量的压力预估 这个假设这个网站预估的用户数是 1000万，那么根据28法则

你如何考虑服务化 # 集中式与分布式 要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。 # 集中式 集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。 集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 # 分布式 分布式就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 拿电商网站来说，我们一般把一个电商网站横向拆分成商品模块、订单模块、购物车模块、消息模块、支付模块等。然后我们把不同的模块部署到不同的机器上，各个模块之间通过远程服务调用( RPC )等方式进行通信。以一个分布式的系统对外提供服务。 # 服务化 提到分布式，一个不得不提的词就是服务化

文章作者：莫璐怡 Pony.ai 编辑整理：Hoh Xil 内容来源：Pony.ai & DataFun AI Talk 出品社区：DataFun 注：欢迎转载，转载请在留言区留言。 导读：本次分享的主题为打造最可靠的自动驾驶基础架构。主要内容包括如何做 Pony.ai 自动驾驶系统的基础架构，涉及到的技术困难，以及我们是如何克服的。 首先先了解下传统互联网公司的基础架构： 数据基础设施，会包括大规模的数据库、分布式的文件系统； 计算平台，可能会需要大量的服务器、大数据平台、容器的管理机制； Web 服务管理，同时还会有各种各样的 Web Service，不停的迭代来满足新的业务发展。 这是传统互联网公司要做的事情，但是对于自动驾驶公司和 Pony.ai，在这样的架构基础上我们还会做哪些事情？ 这是 Pony.ai 的基础架构，包含了所有传统互联网公司要做的事情，除此之外，还需要做如下事情： 自动驾驶车载系统，如何支持各种各样的AI技术、算法，如何控制车辆，这都依赖于自动驾驶车载系统来完成。 大规模仿真平台，Pony.ai 每天至少会跑 30W 公里的仿真测试（很多自动驾驶公司一年跑的里程可能只有百万级别），这点对于自动驾驶测试来说非常重要。 车队运营基础平台，Pony.ai 要打造自己的移动出行服务，需要基础平台来支持 Robotaxi 的运营。 可视化平台与人机接口

一.软件架构的演进 1.单体结构 前端+中间件业务逻辑层+数据库层 2.分布式应用 中级架构，分布式应用 中间层分布式+数据库分布式 解决了高并发问题，降低了耦合度，责任清晰，扩展方便，部署方便，提高代码的复用性。 系统交互要使用远程通信，接口开发增大工作量 3.微服务架构 中间层分解，将系统拆分为很多的小应用（微服务） 4.Serverless架构 二.23种设计模式（日记中有） 三.今日份Java问题 1.JDK、JRE、JVM三者之间的关系，以及JDK、JRE包含的主要结构有哪些 2.为什么要配置path环境变量，如何配置 3.常见的几个命令行操作有哪些 来源： https://www.cnblogs.com/codekaterina/p/11891995.html

技术架构是以 Spring Framework为核心容器，Spring MVC为模型视图控制器，MyBatis作为数据访问层， Apache Shiro为权限授权层，使用Ehcahe对常用数据进行缓存。采用分层设计、双重验证、提交数据安全编码、密码加密、访问验证、数据权限验证。使用Maven做项目管理，提高项目的易开发性、扩展性。 MyBatis 本是 apache 的一个开源项目 iBatis , 2010年这个项目由apache software foundation 迁移到了google code，并且改名为MyBatis 。2013年11月迁移到Github。 iBATIS一词来源于“internet”和“abatis”的组合，是一个基于Java的 持久层 框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAOs） 来源： https://www.cnblogs.com/hshy/p/11897132.html

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐