架构

一直在说 Django REST framework ，那它到底是什么，你是怎么理解的呢？我查了一些资料，对Django REST framework有了一些粗浅的理解，记录下来。（通常简称Django REST framework为DRF框架）。 ☞ github链接 。 从字面理解开始 仅从字面意思理解的话，Django和framework指的是Django，框架。那REST呢？ REST是Representational State Transfer的简称，中文翻译为“表现层状态转化”，REST与技术无关，代表的是一种软件架构风格，遵循REST的架构风格，称为RESTful。 REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。 他在介绍他的论文时说到： “网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。” Fielding将他对互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写。 如果我把rest译为：使人轻松的，让人得到休息的

架构师，我们程序员打怪升级的主要方向，它不像某些技能报个培训班就可以获得。胜任架构工作需要具备许多技能，如果想尽快转型升级至架构师，那你必须在日常工作中有意识地储备这些技能。网络上有不少架构师技能图谱，但高质量的很少，大部分都是东拼西凑出来的，脉络不够清晰，层次不够分明，杂乱无章，缺乏逻辑，就像拿着错乱的武学秘籍练功，练不成真本领还是小事，就怕走火入魔、浪费时光。 ​ 俗话说：一口吃不成胖子。从程序员到架构师也无法一蹴而就，它是一个循序渐进、稳步提升的进阶过程，每个阶段有每个阶段需要掌握的技能，多项技能之间还存在先后顺序，既有硬技能还有软技能。如果以硬技能为例，我们可以将其分解成下列几个维度： 从职位晋升的角度看，程序员都要历经初级开发工程师、中级开发工程师、高级开发工程师这三个阶段才能进阶至架构师，此后还有架构专家、高级架构专家等职位，再往上就是首席架构师、首席技术官。 从代码规模的角度看，程序员都是从编写函数、类开始起步的，再逐步负责单个模块、子系统、系统、平台等，代码规模从小到大，关联关系从内到外，复杂度变得越来越高，往上有系统群、生态圈等。 从技术堆栈的角度看，程序员入行只要懂某门编程语言就可以了，进阶时需要钻研不同编程语言、开发框架、应用容器、语言运行时、数据库、操作系统、网络协议等，这样才有能力把握各种类型的系统。 从设计方法的角度看，程序员从面向对象设计开始起步

业务系统中，通常会遇到这些场景：A系统向B系统主动推送一个处理请求；A系统向B系统发送一个业务处理请求，因为某些原因（断电、宕机。。），B业务系统挂机了，A系统发起的请求处理失败；前端应用并发量过大，部分请求丢失或后端业务系统卡死。。。。这个时候，消息中间件就派上用场了--提升系统稳定性、可用性、可扩展性。 一、消息中间件 消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 总体来说，消息中间件有以下作用:降低耦合、流量消峰（防浪涌）、可靠性传输、事件驱动 1.降低耦合:通过发布订阅的方式松耦合 我们以注册业务为例，注册成功会发送短信、邮件给用户来确认，传统架构模型是这样： 邮件业务和短信业务的代码是写在用户注册的流程里，无论是通过接口的方式来实现，还是远程调用的方式来实现，耦合度都很高，现在，新增一个需求，用户注册完成以后不发送邮件了，而是给用户“增加积分”，我们来分析这几种情况： 第一、都在一个业务系统内通过代码堆积、接口调用的方式来实现注册成功后的业务处理，我们需要改动注册代码，上线时需要启停应用，这种方式耦合度最高。 第二、通过远程调用的方式，代码类似如下 当我们要新增业务处理时，如下 还是要改动主流程代码

一、什么是设计模式？ 什么样的程序员是一个好的程序员？能熟练应用，并用编程语言解决各种问题，才算是真正的“会”。编程语言就像是世界上任何有意义的东西一样，它在一直变化，一直进化，此刻学会的编程语言，到了下一刻，就可能有新东西出来，跟上它进步的节奏，本身就是一件非常费精力的事，更别说去在这个基础上，去“会”第二门编程语言了。 程序员，更多的体现不应该在他会使用多少“工具”，而是他能使用这些“工具”，创造多么大的成绩，解决多么大的问题。掌握解决问题的方法，能用自己精通的编程语言解决各种问题，这才是成为一个优秀程序所必备的。 正因为如此，我们才需要学习设计模式。设计模式是面对各种问题进行提炼和抽象而形成的解决方案。这些设计方案是前人不断试验，考虑了封装性、复用性、效率、可修改、可移植等各种因素的高度总结。它不限于一种特定的语言，它是一种解决问题的思想和方法。 二、设计模式的意义 过去常常被当作软件行业标杆的“软件工程”设计模型，逐渐让出了它的半壁江山，给了一种叫作“敏捷开发、快速迭代”的软件开发方式。 快速迭代的环境下，需求就显得不那么明确，需求常常伴随着整个项目的进行而变化。需求的不确定性，对程序编写的要求就会比较高了。首先要考虑各种可能需求的兼容，但考虑的需求越多，就很容易陷入整个软件架构设计的深渊，不可自拔。 设计模式对需求变更与代码重用的考虑，可以被作为软件设计的参考

Elastic Search 分布式架构分析 来源： https://www.cnblogs.com/yucongblog/p/11945782.html

1. 新建工程选择Framework 2.拖入要制作为framework的代码 3.设置build setting 搜索linking,将Dead Code Stripping设置为NO, Mach-o Type设置为Static Library,下面是已经设置好的 4.设置最低版本 5.设置build phases中的public头文件和private头文件 6.设置scheme为release 7.选中Products中的.framework,showInFinder,发现无法打开,里面暂且无内容 选中一个模拟器,command+B编译 选中真机,command+B编译 再次选中.framework,showInFinder,发现已经有内容了 分别是真机和模拟器对应的framework,已经打包好了. 8.查看framework所包含的架构 lipo -info 下图标红的文件路径 结果,真机包含armv7和arm64的架构 查看模拟器,包含i386架构和x86_64架构 9.合并真机和模拟器支持的架构 lipo -create 真机文件路径 模拟器文件路径 -output 自定义合成文件路径 自定义合成路径可直接写真机路径,会覆盖真机路径下的文件 10.再次查看合并后支持的架构,发现已经合并好了 11.拖入framework,使用 成功! 来源： https://www

本文详解canal的整体架构。 一、整体架构 说明： server代表一个canal运行实例，对应于一个jvm instance对应于一个数据队列 （1个server对应1..n个instance) instance模块： eventParser (数据源接入，模拟slave协议和master进行交互，协议解析) eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作) eventStore (数据存储) metaManager (增量订阅&消费信息管理器) 二、各模块架构 2.1 Parser 整个parser过程大致可分为几步： Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点） Connection建立连接，发生BINLOG_DUMP命令 Mysql开始推送Binary Log 接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功 存储成功后，定时记录Binary Log位置 2.2 Sink 说明： 数据过滤：支持通配符的过滤模式，表名，字段内容等 数据路由/分发：解决1:n (1个parser对应多个store的模式) 数据归并：解决n:1

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

要好好使用 Impala 就得好好梳理一下他得结构以及他存在得一些问题或者需要注意得地方。本篇博客主要想记录一下对 Impala 架构梳理以及使用上的 workaround。 Impala 简介 首先我们来了解一下在 Impala Guide 中 Impala 对自己的定位 Impala is an addition to tools available for querying big data. Impala does not replace the batch processing frameworks built on MapReduce such as Hive. Hive and other frameworks built on MapReduce are best suited for long running batch jobs, such as those involving batch processing of Extract, Transform, and Load (ETL) type jobs. Impala 认为自己是大数据查询工具的补充，对于长时间的 batch work 还是推荐使用基于 mapreduce 的方式来处理超大量数据。因为那更稳定可靠。 Impala 目前已经从 Apache 孵化项目中毕业，由 Cloudera 公司捐赠后

来源： https://www.cnblogs.com/xietianjiao/p/11937473.html