架构设计

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最后我们再看看NIO方面最著名的框架Mina，抛开Mina有关session和处理链条等方面的设计，单单挑出前端网络层处理来看，也采用的是与Jetty和Tomcat类似的模式，只不过它做了些简化，它没有隔开请求侦听和请求处理两个阶段，因此，宏观上看它只分为两个阶段。 先看看它的类图： 其中： SocketAcceptor起线程调用SocketAcceptor.Work负责新连接侦听，并交给SocketIoProcessor处理 SocketIoProcessor起线程调用SocketIoProcessor.Work负责侦听所管辖的channel队列， select到新请求后交给IoFilterChain处理 IoFilterChain组装了mina的处理链条 在整个服务端处理请求的过程可以分为两个阶段，时序图如下所示： 阶段一：监听并建立连接 阶段二： 监听并处理客户端的请求 总结来看Jetty、tomcat和Mina，我们也大概清楚了该如何基于NIO来构架网络服务器，通过这个提炼出来的模式，我写了个很简单的NIO Server，在保持连接的情况下，可以很轻松的保持6万连接（由于有65535连接限制），并能在负载只有3左右的情况下（4核），承担3到4万的TPS请求（当然做的事情很简单

分布式架构设计 1.分布式架构的基本理论 2.SOA架构和微服务架构 3.领域驱动设计及业务驱动划分 ==================================== 一. 分布式架构的基本理论 1.CAP理论 一个经典的分布式系统理论。CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。 一致性（Consistency） 所有节点上的数据必须时刻保持一致 可用性（Availability） 可用性是指服务一直可用，而且是正常的响应时间 分区容错性（Partition tolerance） 系统应该持续提供服务，即时系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂；服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系 总结： CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。 2.BASE理论 从前面的分析中知道：在分布式（数据库分片或分库存在的多个实例上）系统下，CAP 理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么样的高可用方案都是徒劳

学习目标 　　听<软件架构相关音频>软件开发架构一节 待解决问题 　　构件的概念 ? 　　如何表达一个项目的架构,用什么图表? 　　架构设计作为一个系统开发的中间产品,交付的是什么内容? 　　各种架构风格的适用场景? 学习内容(耗时:40min) 软件架构是什么 　　软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述，构建的相互作用（连接件）、知道构件集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织架构和拓扑结构，并且显示了系统需求和构建还见的对应关系，提供了一些设计决策的基本原理 架构设计的重要性 架构设计好比房子的钢筋水泥,定下了结构,才能撑的起整个系统.尤其是在大型软件开发中 软件架构的重要性越来越大 需求分析 -- 〉 架构设计 --〉 软件分析 软件架构 应该是项目中的一个可交付的中间产品 　　 软件架构的意义(9个意义 ) 架构是项目干系人进行交流的手段 架构是早期设计决策的体现 架构明确了对系统实现的约束条件 架构决定了开发和维护组织的组织结构 架构制约着系统的质量属性 架构使推理和控制更改更监督 架构有助于循序渐进的原型设计 架构可以作为培训的基础 架构是可传递和可服用的模型　 架构的发展阶段(4个阶段) 无架构设计阶段 萌芽阶段 初级阶段 高级阶段 　　 如何表示软件架构(软件架构建模) 　　　　 结构模型（常用） 核心

MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。 一、MVC MVC模式的意思是，软件可以分成三个部分。 视图（View）：用户界面。 控制器（Controller）：业务逻辑 模型（Model）：数据保存 各部分之间的通信方式如下。 View 传送指令到 Controller Controller 完成业务逻辑后，要求 Model 改变状态 Model 将新的数据发送到 View，用户得到反馈 所有通信都是单向的。 MVC优点： 耦合性低 重用性高 生命周期成本低 部署快 可维护性高 有利软件工程化管理 MVC缺点： 没有明确的定义 不适合小型，中等规模的应用程序 增加系统结构和实现的复杂性 视图与控制器间的过于紧密的连接 视图对模型数据的低效率访问 一般高级的界面工具或构造器不支持模式 在MVC里，View是可以直接访问Model的。从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。 所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了

版权声明：本文由韩伟原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/252 来源：腾云阁 https://www.qcloud.com/community 接上篇 如何提高程序员的生产率 (1) 三. 开发过程 沟通 软件通常都需要经过很多人和很多次的沟通才能生产出来，但是沟通本身又往往会影响软件的开发速度。这是一段很矛盾的关系。好的沟通方法能降低开发中因为信息不透明导致的开发资源浪费，而又尽量减少沟通所占用的精力。 1. 需求沟通 在任何一个软件产品中，如何应对需求的变更，都是至关重要的。需求一直是软件工作得以成功或者失败的最重要因素。软件开发中很多技术和方法都是围绕着需求来设计的。 需求的沟通是需求工作的第一个环节。首先沟通的对象必须是经过挑选的，以免添加不必要的需求混乱。最佳的需求沟通是和用户或者用户代表。但是他们往往他们缺乏必要的计算机知识。而程序员却很少有丰富的需求领域的知识。这个鸿沟需要双方共同去弥补，最重要的做法是，不要光靠口说。 程序员应该认真研究需求领域的知识，仔细查看涉及的单据、原型产品、现有工作流程等，而且必须用笔记录下来，之后再去整理问题，逐条咨询用户。在仔细了解情况之前，不宜开始设计整体程序结构。 当你有一定了解之后，程序员就可以动手开发一个快速的原型，如果没有足够资源

「OneAPM 技术公开课」由应用性能管理第一品牌 OneAPM 发起，内容面向 IT 开发和运维人员。云集技术牛人、知名架构师、实践专家共同探讨技术热点。继北京站第一场火爆上演之后，第二场将于9月19日在上海拉开帷幕。 ##大型网站的灵魂——性能 第二期 OneAPM 技术公开课将会在9月19日正式开讲，本次公开课将围绕「架构设计2.0——性能为王」为主题。随着互联网行业的高速发展，用户体验被提升到一个新的高度，而网站性能又是影响用户体验最重要的因素。对很多大型网站而言，通过一些常见的技术架构，系统的稳定性和高可用性都能够得到很好的保证，而「性能」已然成为很多架构师最棘手的难题。 其实，对每个架构师而言，都应该用更精深的方式来帮助网站实现性能的优化和改进。本次公开课由应用性能管理领军企业 OneAPM 主办，特别邀请了来自 eBay、苏宁易购、携车网、前1号店的架构师和实践专家进行一场别开生面的技术实践分享。 ##本次公开课主要包括以下4个主题： 前1号店运维总监、首届北大互联网 CIO-CTO 班副班长 邱仔松 : 《如何使用混合云的解决方案备战双11？》 携车网 CTO 洪涛 & OneAPM 华东售前技术总监 汪为敏 : 《实践分享：如何使用工具来优化网站架构和性能？》 苏宁金融技术架构师 郭贤亮 :《如何使用 LVS 构建一个高可用、高性能的服务集群？》 eBay

上篇我们介绍了下面这个简单的语音聊天室的架构，遗留了两个问题。首先， 语音服务器是怎么转发语音数据的？ 我们直接上图。图中虚线框表示连接到同一台语音服务器。当A说话的时候，客户端将语音数据上传到A所连接的语音服务器；语音服务器向房间服务器查询A所在房间的其他用户（B-E）所在的语音服务器IP，分几种情况：对于同服务器用户B只需要下发语音数据，对于其他服务器上的用户（C-E）需要转发给相应的语音服务器，其他语音服务器收到转发数据后，根据房间信息，下发给同房间的用户。 有一个细节需要注意， 房间服务器是主动给语音服务器同步房间架构的 。因为语音服务请求量非常大，如果每次转发的时候都查询房间架构信息，那么房间服务器/数据库将成为瓶颈。因此语音服务器本地缓存了房间架构信息（当然缓存也会导致其他的问题，以后会专门讨论）。缓存的同步机制采用用户进退房主动触发房间服务器广播和房间服务器定期推送相结合，这样可以有效 保证网络丢包情况下的数据一致性 。 另外一个问题是 目录服务器是否有点多余？ 答案自然是否定的。当同一房间用户量还比较少的情况下，目录服务器的确可以省略，客户端可以通过DNS解析域名得到语音服务器的IP地址进行连接。 但是，当用户量非常大的时候，DNS缓慢的刷新机制不能满足快速扩容和缩容。目录服务器还有一个重要的作用是 负载均衡 ，相比DNS手工配置的简单的负载均衡策略

文章节选自 《Netkiller Architect 手札》 由于Java 语言的编译与重启不可抗拒缺陷，所选择使用ＰＨＰ弥补这个缺陷。 在合适的场景中使用PHP 为 Java 提供 SOA 服务有很多优势，最大的优势就是升级，能够随时升级，即时生效，服务不中断。 任何一种语言都有其擅长的一面，多种语言互补是一种趋势。 14.4. Service-oriented architecture (SOA) SOA 与 REST很多相同之处，目前SOA主要是基于SOAP实现，也有基于MQ的实现。而REST只限于HTTP POST/GET/PUT/DELETE等等。 我个人比较喜欢机遇TCP的SOA实现，不喜欢SOAP大量XML传输。 14.4.1. SOAP实现 这里提供一个简单的机遇SOAP实现的SOA框架 index.php入口文件 <?php define ('CONFIG_DIR', '../config/'); define ('LIBRARY_DIR', '../library/'); define ('DEBUG', false); //define ('DEBUG', ture); require_once(CONFIG_DIR. 'default.php'); $remote_addr = $_SERVER['REMOTE_ADDR']; if(!in_array(

该平台面向三类用户：下家（合作商），上家（代理商），平台管理员。该平台提供给下家的功能包括：合作商入驻、充值价格查询、充值接口，充值结果查询、对账接口等。平台可以接入多个上家，根据每个上家充值接口的服务质量，充值时动态切换上家，目前暂时只接入一个上家。平台还提供了手机号码归属地查询接口，可以自动切换该接口的多个实现，以实现该接口的高可用。手机话费空中充值的流程如下：用户在下家网站上输入手机号码和充值面值，下家调用平台的充值价格查询接口，用户确认价格并支付成功之后，调用平台的充值接口。平台提供了充值结果异步通知接口。下家与平台之间的通讯协议是使用https，平台与上家之间的通讯协议是使用TCP。使用netty封装了平台与上家之间的通讯，可以自定义协议和很好的解决TCP的拆包，粘包等问题，因为使用l了TCP的keepalive。所以会使用心跳维持这个连接。每次调用上家充值接口，会传递一个不重复的有规则的序列号，序列号的生成使用了MySQLMaxValueIncrementer，如下配置所示： <bean id="messageSequence" class="org.springframework.jdbc.support.incrementer.MySQLMaxValueIncrementer"> <property name="incrementerName" value="t

1.Dubbo是什么？ Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。 RPC 指的是远程调用协议，也就是说两个服务器交互数据。 2.Dubbo的由来？ 互联网的快速发展，Web应用程序的规模不断扩大，一般会经历如下四个发展阶段。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起即可。 垂直应用架构 当访问量逐渐增大，单一应用按照有业务线拆成多个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 3.Dubbo的主要应用场景？ 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。