应用架构

一：Django框架应用 1：web应用： 运行在浏览器上的应用 2：c/s，b/s架构 　　client/server：客户端服务器架构，c++ 　　browser/server：浏览器服务器架构，java，Python 　　底层均是基于socket 3：Python web框架 　　a:socket b:页面路由 c:模板渲染 　　Django a用到wsgiref b自己写的 c 自己写的 功能全面 　　Flask a用的第三方 b自己写的 c自己写的 小而轻 　　Tornado a自己写的 b自己写的 c自己写的 支持高并发 二：原生socket服务 目录结构: 　　part1 　　　　-- index.html 　　　　-- server.py 基础socket服务： import socket # 利用socket建立服务器对象 server = socket.socket() # 设置ip和端口 server.bind(('127.0.0.1', 8001)) # 设置监听 server.listen(5) print('服务器设置成功') print('浏览器访问：http://127.0.0.1:8001') while True: # 阻塞等待客户端数据 client, address = server.accept() # 接收数据 data = client

摘自： https://www.cnblogs.com/mrhelloworld/p/12388859.html 技术架构演变 　　 　　 　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 　　 　　 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？ 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况动态管理。 流动计算架构

最近研究了一段时间的Kubernetes，将我们服务的测试环境服务部署到了Kubernetes上，上周末在团队中分享了下，顺便整理成文章。 阅读对象：对Kubernetes尚未深入了解的同学 首先，为什么要用Kubernetes? 使用一个工具先要梳理下使用这个工具的目标，我们不是为了工具而用工具。 Kubernetes的目标用一张被很多人引用过的图来说明最好： 一句话，Kubernetes的目标是让你可以像管理牲畜一样管理你的服务，而不是像宠物一样，同时提高资源的利用率，让码农关注在应用开发本身，高可用的事情就交给Kubernetes吧。这个图本来是openstack提出的，但纯粹IaaS层的解决方案实现不了这个目标，于是有了Kubernetes。 Kubernetes和Borg系出同门，基本是Borg的开源改进版本，引用Google Borg论文里的说法： it (1) hides the details of resource management and failure handling so its users can focus on application development instead; (2) operates with very high reliability and availability, and supports applica- tions

在分布式系统中，实现强一致性并不容易。即使2PC、3PC阶段提交，也无法保证绝对的强一致性。 我们也不能因为极小的不一致性概率，导致系统整体性能低下，或者扩展性受到影响，并且架构也变得极其复杂。因此，在2PC/3PC提交缺乏大规模应用的情况下，最终一致性是一个较好的方案，在业界得到了大量使用。 一、重试机制 如下图所示，Service Consumer 同时调用 Service A 和 Service B，如果Service A 调用成功，Service B 调用识别，为了保证最终一致性，最简单的办法是重试。 重试的时候，要注意设置Service Consumer 的超时时间， 避免长时间等待或卡死，耗尽资源。 Consumer 重试时，需要注意如下几个方面： 超时时间； 重试的次数； 重试的间隔时间； 重试间隔时间的衰减度； 具体实现细节，可以参考《 基于Spring-tryer 优雅的重试方案》。 二、本地记录日志 通过本地记录日志，然后收集到分布式监控系统或者其他后端系统中，启动一个定期检查的工具。根据实际情况，可以选择人工处理。 日志格式：TranID-A-B-Detail TransID为事务ID，可以生成一个随机序列号； Detail 为数据的详细内容； 如果调用A成功，则记录 A success； 如果调用B失败，或者出现故障，没有记录等等，也就是日志中没有B

技术架构演变 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？ 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况动态管理。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

上周六参加了一场由淘宝的架构师，曾宪杰先生主讲的淘宝网架构分享。然后马上就出差了，一直没来得及总结，今晚比较有空，把这次听到的比较有启发的观点记录一下 一、为什么stateless比较有利于实现水平伸缩 关于什么是stateless的扫盲，见这个贴： http://kyfxbl.iteye.com/blog/1831869 一般有一个共识，就是把应用做成无状态的，会比较容易实现水平伸缩。但是以前一直有一个想法，就算应用是有状态的，也可以做成水平伸缩：只需要在负载均衡那里做一个session绑定就可以了，根据某种标识，把请求固定地发送到特定的server上 但是相对于有状态，stateless是更好的，主要有3个原因： 1、负载均衡不需要做session绑定，也就可以用更简单的算法，比如随机、取模等，把请求分配到任意server上，因此相对于session绑定的做法，性能会比较好 2、也是性能的问题，在7层网络模型中，session位于第7层，负载均衡如果是基于session的算法来决定要怎么分发请求，性能的损耗也会比较大 3、如果某一台server down掉了，后续的请求就没法继续往这台server发了，影响可用性 二、为什么淘宝开发session框架 如果将请求所需的信息，都放在cookie里，确实就不需要session框架了，而且也比较容易实现stateless

微服务 强调的是服务的大小，它关注的是某一个点，是具体解决某一问题/提供落地对应服务的一个服务应用， 狭义的看，可以看做Eclipse里面的一个个微服务工程/Module 微服务架构 微服务架构是一种架构模式，它提倡将单一应用划分成一组小的服务，服务之间相互协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相协作(HTTPPAII的RESTfull),每个服务都围绕着具体业务进行构建，并且能够独立的部署到生产环境，类生产环境等，另外，应避免统一的，集中式的服务管理机制，对具体的服务而言，应根据业务上下文，选择合适的语言、工具进行构建 本文参考资料: 尚硅谷周阳Spring Cloud讲解和翻译 ， 业界大牛 马丁.福勒(Martin Fowler)发布的论文 本文若有错误请指正，互相学习，加油! 来源： CSDN 作者： 小小辉先生 链接： https://blog.csdn.net/Modesty_Boy/article/details/104551301

码农小光 的文章的记录 单机架构 第一次演进：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 产品时，代表的是无需理解、管理服务器，按需使用