应用架构

1Django框架的初使用 说起Django框架，肯定需要首先明确一个概念，即软件框架。下面就是第一个问题： 1 软件框架（software framework） 1.1 概念界定 软件框架：通常指的是为了实现 某个业界标准 或完成 特定基本任务 的软件组件规范，也指为了实现 某个软件组件规范 时，提供规范所要求之 基础功能的软件产品 。 1 软件框架是具有基础功能的软件产品： 基础功能：可以理解为为了满足某类业务场景而设定的功能。 软件产品：软件框架是为了针对某一类软件设计问题而产生的。 1.2 形象理解 其实可以将软件框架想象成一个公司，公司中有各个职能部门，每个部门各司其职，通过部门之间的配合来完成工作，这些部门就形成了一个公司的组织架构。 软件框架也是如此，只是说一个公司，它是针对某一市场而成立的，而软件框架的设计是针对某一类软件问题而设计的， 其目的主要是提高软件开发效率 。 软件框架是由各个模块组成，各个模块都会有不同特定的功能。模块与模块之间相互配合来完成软件的开发。 在介绍完软件框架是什么之后，就需要研究一下具体的框架模式，这里介绍下MVC框架模式： 2 MVC 2.1 框架、设计模式、架构 笔者曾很困扰于这问题，查找了很多相关文字，作下总结和体会表述： 基本概念： 框架 通常是 代码重用 ； 设计模式 是 设计重用 ，其只有实例化之后才能用代码表示； 框架 则

这是之前规划设计的IT基础架构运维规划方案，总结自己一段时间的运维经验 相关敏感信息已经去除 学无止境啊 XX运维工作架构规划 从2016年10月XX的运维工作到现在已经有两年多了，期间进行了很多调整，部署了很多业务系统，从一开始的混乱无序，到现在算是小有成效了。现在我们需要进一步完善现有运维工作，规划完整的架构，方便日后进行调整，保证能够科学而又高效的完成运维工作，提高客户满意度。 1.整体架构设计 整体架自下而上分为两个部分，基础环境和上层业务应用。 基础环境主要是提供的基础虚拟机化环境和存储支持，同时包括各种网络基础环境。 上层应用由客户业务、运维支撑和第三方业务系统构成，主要是基于虚拟机的应用软件和解决方案。 广电的基础环境主要构建是基于kvm虚拟化解决方案的超融合nutanix环境和基于vmware的vsphere虚拟化解决方案环境组成，两者为不同的异构的虚拟化，中间底层网络全部连通，相互共享网络资源和存储资源，为整体的架构提供一个虚拟化层从而支撑上层其他业务系统。值得说明的是，目前我们无法两种不同的虚拟化环境进行统一管理和调度，虽然他们都可以提供完整的虚拟机生命周期管理。 1.1. nutanix的虚拟化环境 Nutanix的虚拟化环境组网如下所示： 这是一个稳定的组网架构，从2017年3月部署后，基本没有变更过，运行可靠，可用性高，性能强悍

目录 前言 一、微服务介绍 1.什么是微服务 微服务由来 为什么需要微服务？ 3.1 早期的单体架构带来的问题 3.2 微服务与单体架构区别 3.3 微服务与SOA区别 微服务本质 什么样的项目适合微服务 微服务折分与设计 6.1 微服务设计原则 微服务优势与缺点 7.1 特性 7.2 特点 7.3 缺点 微服务开发框架 Sprint cloud 和 Sprint boot区别 二、微服务实践先知 客户端如何访问这些服务？（API Gateway） 服务之间如何通信？（服务调用） 这么多服务怎么查找？（服务发现） 服务挂了怎么办？ 微服务需要考虑的问题 三、微服务重要部件 微服务基本能力 服务注册中心 2.1 zookeeper服务注册和发现 负载均衡 3.1 负载均衡的常见策略 容错 4.1 容错策略 熔断 限流和降级 SLA API网关 多级缓存 超时和重试 线程池隔离 降级和限流 网关监控和统计 前言 到底什么是微服务？为什么要用微服务？微服务主要来做一些什么？微服务有哪些优势？什么样的服务属于微服务？本文所有资料来源网络，我只是整理一下，总结一下。仅供参考。 一、微服务介绍 1.什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释

RESTful 架构详解 分类 编程技术 1. 什么是REST REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。 REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。 2. 理解RESTful 要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。 下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联

1. 什么是REST REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。 REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。 2. 理解RESTful 要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。 下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。

场景：因为自己做的后台，一直有为前端提供接口，一直知道用的是restful框架，可是没有深入理解，先整理如下。 转载自：http://kb.cnblogs.com/page/512047/ http://kb.cnblogs.com/page/521718/ 1. 什么是REST 　　REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到：“我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。” 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。 　　REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。 　　 2. 理解RESTful 　

单体应用架构 垂直应用架构 分布式之RPC架构 分布式之SOA架构 分布式之微服务架构 微服务架构： 微服务虽小，五脏俱全。 解决的问题：微服务与微服务之间的系统调用 来源： CSDN 作者： 树叶要走风怎么挽留 链接： https://blog.csdn.net/weixin_44993313/article/details/104041113

IOING 在做些什么？ IOING 在你的代码和浏览器之间架设了一个中间解释层，该解释层提供了一套新的语法来填补浏览器所不具备的能力。 SPA 开发痛点 开发一个 SPA 应用的痛点是不同模块页面的状态保存，当从一个页面跳转到另一个页面的时候窗口的所有状态都将被清空重载，历史页面与当前页面将不产生任何联系，这个过程是一个拆毁重建的过程，如果你要回到历史同样只能再次拆毁重建，并且在这个过程中不可避免的出现加载期的窗口白屏，显然这样的丑陋效果不符合一个高贵 App 的设定，但正因这种方式前后页面不共存的简单特性也使得开发逻辑变得简单，开发者只需考虑单个页面的逻辑即可，而每一次新页面的加载都能将之前页面进行完全释放，完全不需要担心高耦合和内存无法完全释放的问题，这也算是传统技术的优点，虽然简单粗暴，但是它很管用。那到底有没有两全其美的办法呢？ 传统模式带来的挑战 和 SPA 应用不同的是多页面应用往往相对要变得简单，页面与页面之间不需要有复杂的数据交换，也无需保存页面历史状态，因此使用传统技术最适合不过了。 而 SPA 应用则要协调页面间的关系，它的每一个模块都可能是联动的，而且需要保持窗口的数据状态，因而催生了另一个技术的流行，即通过使用 Ajax 和模版将新模块内容载入到当前页面，但这也导致新载入模块的脚本和 DOM 树内容在主文档下不断堆积，且在不需要时也无法将其很好移除和释放

文章目录 DDD分层与传统三层区别 DDD分层详解 四层架构图 分层作用 领域对象 DDD编码实践 代码结构描述 领域模型注入仓储类的问题 DDD分层与传统三层区别 根据DDD领域驱动设计原则，对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在 DDD 分层结构中既有联系又有区别， 个人认为主要有如下异同： 在架构设计上，在 DDD 分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层 其中Application划分为很薄的一层服务，非核心的逻辑放到此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更为精确的业务规则集合，通过领域对象去阐述说明。 在建模方式上， DDD 分层的建模思维方式有别于传统三层 传统三层通常是以数据库为起点进行数据库分析设计，而 DDD 则需要以业务领域模型为核心建模（即面向对象建模方式），更能体现对现实世界的抽象。 故 在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有的业务领域模型的抽象表达 。 在职责划分上，基础设施层涵盖了2方面内容 持久化功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现 通用技术支持，一些公共通用技术支持也放到基础设施层去实现。 DDD分层详解 四层架构图 在该架构中，上层模块可以调用下层模块，反之不行。即 Interface ——>

Vue.js 和 MVVM 小细节 MVVM 是Model-View-ViewModel 的缩写，它是一种基于前端开发的架构模式，其核心是提供对View 和 ViewModel 的双向数据绑定，这使得ViewModel 的状态改变可以自动传递给 View，即所谓的 数据双向绑定 。 Vue.js 是一个提供了 MVVM 风格的双向数据绑定的 Javascript 库，专注于View 层。它的核心是 MVVM 中的 VM，也就是 ViewModel。 ViewModel负责连接 View 和 Model，保证视图和数据的一致性，这种轻量级的架构让前端开发更加高效、便捷。 为什么会出现 MVVM 呢？ 我接触MVVM 是在2015年，可以说2015年是MVVM 最火热的一年，而在这之前，我所知道的就是MVC, MVC 大约是在5年前，也就是2011年的时候接触的，那时候刚学编程语言，学的Java，而Java 中经典的 SSH 框架就用来构建一个标准的MVC 框架。说实话，MVC 用了这么多年，但始终没有很深刻的理解，只停留在用的层面， 一直到接触 Vue.js 之后，研究了MVVM 架构思想，然后再回头看 MVC ，才有一种豁然开朗的感觉~ MVC 即 Model-View-Controller 的缩写，就是 模型-视图-控制器 , 也就是说一个标准的Web 应用程式是由这三部分组成的