架构

愿景已经确定架构愿景和目标。 需求分析明确架构要解决当前什么问题。 那接下来就是如何着手开始做架构设计。 一、如何开始设计一个架构：方式方法 架构不是像平常写代码一样，对就是对，错就是错，它并无对错之分，是一个取舍的过程。当我们从0开始做架构的时候，的确是比较困难。虽然万事开头难，但是一个好的开始相当于成功了一半，会给我们接下去的工作打下结实的基础。 我的经验步骤是：业务->功能->技术实现->架构综览图 1、业务架构:确定总体架构，核心流程, 是最上层的战略架构. 包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。 没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。 所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。 2、应用架构:确定子系统的功能范围和划分解决方案: 应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作

Daniel Mohl是一名专业的软件工程师/架构师，他的兴趣包括理解各种复杂的编程语言、企业应用架构以及如何搭建业务与技术，他通晓F#、C#、CoffeeScript、JavaScript、Erlang、ASP.NET、MVC、WPF、WCF、Sliverlight、SQL Server等技术。有着多年的软件开发经验。 他经常会被一些有潜力和有前途的程序员问到：“我要怎么做才能成为一名架构师？”说实话，这已经是老生常谈的话题了，答案当然是视情况而定。不过他也根据自己的经验，给大家一些建议，并且提供一些资料，助你快速走上架构师这条道路。 下面是Daniel Mohl所提出的列表，供大家参考： 首先，你必须不断地寻求改善和提升自己。而提升自己的最好方法是阅读，下面有几本书，对我的软件架构技能的提升很大。推荐给大家： 软件架构师应该知道的97件事 企业应用架构模式 敏捷软件开发，原则，模式和实践 企业集成模式 JavaScript语言精髓 利用遗留代码有效地工作 领域驱动设计 企业架构策略 设计模式（四人帮） The Goal SOA设计模式 SOA Principles of Service Design 除了阅读，还有没有其他需要注意的、或者在平时需要关注的东西呢？ 每隔一两年学习一门新语言，F#是个不错的选择。 选择一个重点领域，但是尽可能对许多技术有个高层次的理解

大家好，现在开始本系列的第三部分，按照以下几个步骤来搭建引擎雏形： 1、分析引擎的需求 2、实现最小的3D程序 3、从中提炼引擎原型 4、一步一步地对引擎进行改进，使其具备良好的架构 5、实现与架构相关的功能，如“多线程渲染”、“延迟渲染”等功能 本文进行第一步，分析引擎的需求。 上一篇博文 从0开发3D引擎（七）：学习Reason语言 业务目标 1.手把手教读者如何从0开发3D引擎 2.学习函数式编程及其在3D领域的应用 3.学习3D编程中基础的功能实现，如纹理、光照、模型等 4.学习引擎的设计和架构，如Data Oriented、多线程等 本系列开发的引擎属于最简化的引擎，读者可以根据自己的需要在此基础上对引擎进行扩充，满足自己的应用场景。 范围 简单渲染 引擎只有最基础的光照和纹理功能。 简单交互 引擎只能通过“操作相机”来交互。 适当的扩展 引擎支持主要的扩展方式，如使用脚本组件来插入用户逻辑，实现动态场景。 Feature 最小功能 完全函数式的架构 支持良好的扩展性 优秀的性能 上下文 开发者 开发者是直接使用引擎来开发Web 3D应用的程序员。 编辑器 编辑器属于对引擎的二次开发。它对引擎进行封装，以“所见即所得”的方式向用户提供对Web 3D场景编辑的界面，从而使用户可以很方便地开发Web 3D应用。 功能性需求 GameObject和Component

此系列文章为 极客时间 上 从 0 开始学架构 学习后感悟总结，虽然隔了一段时间了，那么就再看一遍并且进行感悟升华，排版格式上有问题，后期再复习时也会进行更新 架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。 架构设计的主要目的是为了解决软件系统复杂度带来的问题，架构师该做的有的放矢，而不是贪大求全 一.架构复杂度来源---高性能 为了满足业务的所需性能，单机早已无法应当，因此都是采用集群方式来应对，使用集群方式后就会变得更复杂。 很简单的方式，我们加入新机器后便需要再加入任务分配器，从单机就进化成了下图，很好理解 　　 　　 　　随着为了满足业务性能要求增加了新服务器后，引出了一些问题 多了一个任务分配器，它可能是硬件（F5），也更有可能是负载均衡软件（lvs/nginx/haproxy），也可能是自研系统 任务分配器内有算法，使用不同的算法会对我们的性能有不同的改善，不同的业务场景有各自所需的算法 任务分配器与后端业务机器之间的联通问题 一台机器可以承受5000业务量（假定），但是2台并不是1W，实际需要打个8折，即8000，如果业务还比较复杂，那么可能只有5000，我们的收益会越来越低 随着业务量的增加，单台任务分配器都会成为瓶颈，即连任务分配器我们也需要变成集群模式，任务分配器前面也需要选择对应的分配策略（即任务分配器的任务分配器），常用的有DNS 轮询

摘要：本文作者王庆友，前 1号店首席架构师，先后就职于 ebay、腾讯、1号店、找钢网，精通电商业务，擅长复杂系统业务建模和架构分析，目前在中国 B2B 第一电商公司找钢网担任首席架构师，微信号Brucetwins，欢迎一起聊架构。 　　目前讨论架构实操（术）的文章较多，讨论架构理念（道）的较少，本文基于作者在大型电商系统架构方面的一些实践和思考，和大家聊聊架构理念性的东西，希望能够抛砖引玉，推进大家对架构的认识。 　　什么是道，什么是术？道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大路通罗马，罗马是道，大路是术。道为本，术为途，如果事先知道罗马在哪里，那么遍地是路，路路相通。架构也是如此，如果能领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型 、架构境界等。 　　 架构的本质 　　任何系统，自然情况下，都是从有序到无序，这是有科学依据的， 按照热力学第二定律，自然界的一切自发过程都有方向性，一个孤立系统会由有序变为无序，即它的熵会不断增加，最终寂灭。但生物可以通过和外界交互，主动进行新陈代谢，制造 “负熵” 来保证自身有序，继续生存。 　　同样，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展

架构的本质 原文作者王庆友，前 1号店首席架构师，先后就职于 ebay、腾讯、1号店、找钢网，精通电商业务，擅长复杂系统业务建模和架构分析，目前在中国 B2B 第一电商公司找钢网担任首席架构师，微信号Brucetwins。 原文连接 ，读后笔记，全部重新敲了一遍，有一定删减，侵删 目前讨论架构实操（术）的文章较多，而讨论架构理念（道）的较少，本文基于作者在大型电商系统架构方面的一些实践和思考，推进大家对架构的认识。 道与术，道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大道通罗马，如果事先知道罗马在哪，那么遍地是路。架构也是如此，如果能够领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型、架构的境界。 架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”（意为无效性，无序性，不可控等），使系统不断进化。 那架构师如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。 分，则合理定位；合，则有机整体 分的过程是把系统拆分成各个子系统/模块/组件，拆的时候

和MVC框架模式一样，Model模型处理数据代码不变在Android的App开发中，很多人经常会头疼于App的架构如何设计： 我的App需要应用这些设计架构吗？ MVC,MVP等架构讲的是什么？区别是什么？ 本文就来带你分析一下这几个架构的特性，优缺点，以及App架构设计中应该注意的问题。 1.架构设计的目的 通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题。但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。 举个简单的例子： 一个Android App如果只有3个Java文件，那只需要做点模块和层次的划分就可以，引入框架或者架构反而提高了工作量，降低了生产力； 但如果当前开发的App最终代码量在 10W 行以上，本地需要进行 复杂操作 ，同时也需要考虑到与其余的Android开发者以及后台开发人员之间的 同步配合 ，那就需要在架构上进行一些思考！ 2.MVC设计架构 MVC简介 MVC全名是Model View Controller，如图，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码

什么是高并发 高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有 响应时间(Response Time) ， 吞吐量(Throughput) ， 每秒查询率 QPS(Query Per Second) ， 并发用户数 等。 响应时间： 系统对请求做出响应的时间。例如系统处理一个 HTTP 请求需要 200ms，这个 200ms 就是系统的响应时间。 吞吐量： 单位时间(年，月，日，时，分，秒)内处理的请求数量。 QPS： 每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。 并发用户数： 同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。 如何提升系统的并发能力 互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种： 垂直扩展(Scale Up) 与 水平扩展(Scale Out) 。 垂直扩展 提升单机处理能力。垂直扩展的方式又有两种： 增强单机硬件性能，例如：增加 CPU 核数如 32 核，升级更好的网卡如万兆，升级更好的硬盘如 SSD，扩充硬盘容量如 2T，扩充系统内存如 128G； 提升单机架构性能，例如：使用 Cache 来减少 IO 次数，使用异步来增加单服务吞吐量

一.软件开发架构 　　1.c/s架构（client/server） 　　　　　　c:客户端 　　　　　　s:服务器 　　2.b/s架构（browser/server） 　　　　　　b:浏览器 　　　　　　s:服务器 ps:b/s架构的本质也是c/s架构 二.OSI协议 计算机与计算机之间实现远程通信需要有一套公共的标准/协议协议 1.OSI协议 　　OSI七层协议 　　　　　　应用层 　　　　　　表示层 　　　　　　会话层 　　　　　　传输层 　　　　　　网络层 　　　　　　数据链路层 　　　　　　物理连接层 　　OSI五层协议 　　　　　　应用层 　　　　　　传输层 　　　　　　网络层 　　　　　　数据链路层 　　　　　　物理连接层 2.物理连接层 　　基于电信号传输010101001010这种类似的二进制数据 3.数据链路层 　　1.规定的电信号的分组方式 　　2.规定了任何一台接入互联网的计算机都必须有一块网卡 　　　　每一块网卡上面都刻有世界上独一无二的编号 12位16进制数 前6位是厂商编号 后6位是流水线编号 　　　　这12位数叫做mac地址 　　ps:以上两点合称为"以太网协议" 　　交换机 基于以太网协议通信 不能跨局域网通信 4.网络层 　　IP协议 　　规定了只要是接入互联网的计算机都必须有一个IP地址 　　ip地址特点: 点分十进制 　　ip地址最小:0.0

在 tomcat架构分析 (JNDI配置) 一文里，以配置JDBC数据库连接为例，介绍了tomcat中常用的JNDI配置的几种用法。使用这种配置，在app里可以通过JNDI API非常简单的调用相应的资源对象。但是调用越简单，那其背后封装的逻辑越多。就好比汽车分为手动档自动挡一样。对司机而言，自动挡开起来会轻松很多，那是因为很多复杂的操作，已经封装起来由机器来完成了。 本篇就是从代码原理角度来揭示tomcat中JNDI的配置是如何生效的，以及app中的调用逻辑是如何实现的。通过这些，可以看到tomcat中一块比较重要的体系结构，同时加深对JNDI的理解。 上文介绍了两种配置方案，一个是global的配置，在各个app中引用；一个是各个app自己配置资源对象。这两种方案，从实现角度来看，原理一样，只是第一种比第二种多了一层mapping关系。所以为了方便理解，先从第二种方案，即各个app配置自己的资源对象来说明。 另外，需要说明的是，本章涉及的代码 Tomcat源码 JNDI源码(javax.naming.*)，参考OpenJDK项目 先看一个概念图 JNDI体系分为三个部分； 在tomcat架构分析 (容器类)中介绍了StandardContext类，它是每个app的一个逻辑封装。当tomcat初始化时，将根据配置文件