架构设计

自从5月8号写完架构设计三部曲的第一部 如何写架构设计说明书 ，到现在快20多天了，这段时间主要准备了下系统分析师的考试，当然还有各种工作上的杂事，于是也就拖到现在写第二部如何评审架构设计说明书。当然这个是从评审的角度来看的，其实从编制架构设计说明书的角度来看，也可以阐述具体如何编写架构设计说明书，就像高考作文一样，评审总是有些采分点的嘛，那么对于编制架构设计说明书来说，哪些是我们应该准备的采分点呢？我们在编制的过程中需要重点注意哪些章节的哪些内容呢？这就是我接下来想和大家分享的。 根据第一部文章我们知道一篇架构设计说明书大致章节应该是这样的： 文档概述：包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节； 整体架构：主要从整个IT层描述系统所处的位置，与周边关联系统之间的调用关系； 逻辑架构：系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述； 接口设计：包括系统间的接口设计以及内部功能模块之间的接口设计； 数据架构：本系统与上下游系统间的数据流关系，以及本系统关键数据表设计、数据管理策略等； 技术架构：实施此架构需要用到哪些技术能力，有哪些复用能力及风险； 部署架构：系统如何部署，网络拓扑上有何要求，对硬件服务器有何要求，需要几台，是否需要优化服务器参数； 非功能性设计：性能、高可用、可扩展性、可维护、安全性、可移植性等。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 目前网站架构一般分成网页缓存层、负载均衡层、 WEB层和数据库层，我其实一般还会多加一层，即文件服务器层，这样我们在后面的讨论过程中，我们可以依次用这五层对网站架构来进行讨论。 网页缓存层 首先说下这个网页缓存层，比如CDN租赁（效果比公司自己部署Squid/Varnish要好，他们专业，价格低廉，比如快网/CC等（价格80元/M/月不到）而且覆盖的城市更多），自己架设squid/Varnish是次选。另外，很多朋友喜欢尝试自建CDN，这个是一个比较吃力不讨好的活儿，未必能达到预期目标，这块系统架构师在架设网站初期就有规划好，不要等到网站流量及压力巨大时才去规划。事实上，这一层有很多优 秀的开源软件都能胜利，比如传统的Squid Cache，另外，后起之秀Nginx和Varnish因为性能优异，越来越多的朋友尝试在自己的网站使用他们作为自己的网页缓存，事实上，Nginx已经具备Squid所拥有的Web缓存加速功能，此外，Nginx对多核CPU的利用，胜过Squid不少，现在越来越来的架构师都喜欢将Nginx同时作为“负载均衡服务器”与“Web缓存服务器”来使用，大家可以根据自己网站的情况，来决定究竟使用哪种软件来作为自己网站的网页缓存。 负载均衡层 首先说下负载均衡层，我们熟悉的硬件/软件技术有F5，LVS

之前在上课的时候，老师讲到过架构设计总体为分而治之，将系统分为若干模块，逐一击破，类似于秦始皇统一六国，采用的郡县制再逐一统治，形成中央集权。很好理解，大概也明白这个意思，在将概念应用到实际问题时，很多时候还是遇到问题，不是很熟练。我们报考过系统架构师资格考试。发现不知道的问题还有很多，自己的知识量太少，知识知道个大概不知道具体的细节以及对应的解决方案。 架构设计是指软件架构的概念分组成派和决策派两类，组成派以软件本身为描述对象，分析软件组成，决策派以人的决策为描述对象，归纳架构决策的类型。 组成派定义示例： 软件架构将系统描述为计算组件及组件之间的交互。计算组件是泛指，可进一步划分为处理组件、数据组件、连接组件等，可以指子系统、框架、模块以及类等不同粒度的软件单元。 决策派定义示例： 软件架构包括以下一系列问题的重要决策：（1）软件系统的组织；（2）选择组成软件系统的结构元素和它们之间的接口；（3）如何组合这些元素，使它们合成为更大的子系统；（4）架构风格；（5）软件系统的其他特性，例如使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡以及美学等。一个更通俗易懂的决策列举：模块如何划分；各模块的职责为何；每个模块的接口如何定义；模块之间采用何种交互机制；开发技术如何选型；如何满足约束和质量属性需求；如何适应可能发生的变化。 架构分类为：用例驱动的法；模式驱动的方法

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 引言 一般来说，需要 架构 重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。 2. 运筹帷幄 可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去把这50个问题最终解决呢？ 最简单的做法是每次从中挑一个解决，最终总会把所有的问题都解决。这种做法操作起来比较简单，但效果会很差，为什么呢？ 第一个原因是没有区分问题优先级，所有问题都一视同仁，没有集中有限资源去解决最重要或者最关键的问题，导致最后可能出现做了大半年，回头一看好像做了很多事情，但没取得什么阶段性的成果。 第二个原因是没有将问题分类，导致相似问题没有统筹考虑，方案可能出现反复，效率不高。 第三个原因是会迫于业务版本的压力，专门挑容易做的实施，到了稍微难一点的问题的时候，就因为复杂度和投入等原因被搁置，达不到真正重构的真正目的。 以X系统为例，在我加入前，其实也整理了系统目前存在的问题，大的项包括： 可用性、性能、安全、用户体验等 ，每个大项又包括十几二十个子项

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 引言 前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。 架构 师怎么变成了项目经理了，说好的技术呢？ 真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是扯淡！我将“项目管理能力”称之为“文”的能力，“技术能力”称之为“武”的能力，架构师必须文武双全，才能最终把事情搞定！ 2. 文武双全 架构师的“武”体现在很多方面，既有微观层面的，例如如何设计一个高性能的并发框架（可以参考Disruptor，大量的技术细节，例如 CPU cache，cache line，false sharing等 ）；也有宏观层面的，例如采用HBase还是用 MySQL 存储；还有和业务相关的，例如某个功能应该如何设计才能具备可扩展性。业务层面的相关的技术问题，如果没有相关的业务背景，讲起来比较费劲，也不好理解，这里就不展开了。我们讲讲这些重构项目中和业务无关的一些技术。 我被问到的最多的问题其实也是宏观层面的。其中一个主要的问题是“这些系统的业务都不一样，你之前也没有类似业务背景，你怎么识别出M系统重构的目标是数据解耦，S系统重构的目标是高可用呢，X系统重构的目标是系统解耦呢

OO第四单元博客作业 本单元架构设计 第一次作业 第一次作业架构设计比较直接，用一个专门的类存放UML类图，使用 Hashmap 以 UMLCLass 的id为存放每个类下面的属性，操作，关联，继承关系，接口实现等，对接口之间的继承关系也专门设置一个 Hashmap 存放。这么做的好处是直观，存取方便，但需要注意的是每次对 Hashmap 进行 get() 操作时，需要线判断是否 contains() ，如果不判断直接读取到没有存进Hashmap里的 key 会抛出异常。 本次作业的指令除了求类实现的所有接口之外都比较简单，而由于接口支持多继承关系，在搜索类实现的接口时应该类似对图遍历一样进行bfs搜索，这样能保证求得的接口不重不漏。其余的指令只需在对应的 Hashmap 中找到对应存放的 value 即可。 第二次作业 第二次作业的顺序图和状态图的处理与第一次作业类似，对每个顺序图与状态图建立相应的 Hashmap 存放相应的数据，存取操作都与第一次作业没有太多差别。由于本次作业对数据进行了很大程度的简化，在考虑状态转移时不用考虑多种特殊情况，只需对最基本的状态转移做处理即可。对后继状态的搜索同样采取了bfs搜索，能够保证能到达的后续状态不重不漏。 本次作业对循环继承和重复继承的规则检查有些棘手，一开始我本打算顺着继承关系和接口实现关系的 Hashmap 一层一层往上找

1.1 基本结构 基本架构我先用现在市面普及和成熟的mvp(model-view-presenter),我的理念是职责分层，高内聚低耦合。 MVP模式的核心思想： 相对于我们大家以前熟知的mvc来说，mvp把activity中的UI逻辑抽象成View接口，吧业务逻辑抽象成presenter接口，model类还是原来的model。 1.2mvp 模式的作用 1.分离了视图逻辑和业务逻辑，降低了耦合 2.ativity只处理生命周期的任务，代码变得更加简洁 3.视图逻辑个业务逻辑分别抽象到了view和presenter的接口中去，提高代码的可阅读性 4.presenter被抽象成接口，可以有多重具体的实现，所以方便进行单元测试 5.把业务逻辑抽到presneter中去，避免后台线程引用着activity导致activity的资源无法被系统 回收从而引起内存泄露和oom 1.3mvp 模式的使用 创建IPresenter接口，把所有业务逻辑的接口都放在这里，并创建它的实现PresenterCompl(在这里可以方便地查看业务的功能，由于接口可以有多重实现所以也方便写单元测试) 创建IView接口，把所有视图逻辑的接口都放在这里，其实现类是当前的activity/fragment 由UML图可以看出，activity里包含了一个IPresenter

译者序 AWS用户广泛，产品线复杂，AWS发布的白皮书《Architecting for the Cloud-AWS Best Practices》介绍了常见场景下云架构的最佳实践，不仅对于使用AWS的用户，对于广大使用云的用户都有参考意义，新钛云服工程师特意翻译了本白皮书，供广大使用云的用户参考。 译者整理的脑图 摘要 本白皮书适用于在Amazon Web Services（AWS）上的构建解决方案的架构师和开发人员。本白皮书提供有关技术设计模型的架构指导和建议，以及如何应用于云计算环境中。本白皮书提供了在AWS上设计解决方案时的关键概念和差异。本白皮书还讨论了如何利用特定于云计算动态特性的属性，如弹性和基础设施自动化。这些模型可以为对选择、操作状态和实现状态进行更详细的审查提供上下文，就像《AWS Well-Architected Framework》中详细描述的那样。 介绍 将应用程序迁移到AWS，即使没有重大更改（称为直接迁移的方法），也可为组织提供安全且经济高效的基础架构优势。但是，为了充分利用云计算可能带来的弹性和灵活性，工程师必须改进其架构以利用AWS功能。 对于新应用程序，基于云的IT体系架构模型可以帮助提高效率和可伸缩性。这些新架构可以支撑从互联网规模数据的实时分析到具有数千个连接的物联网（IoT），或移动设备的不可预测流量的应用程序的任何内容。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 下面再来看看Tomcat是如何使用NIO来构架Connector这块的。 先看看Tomcat Connector这块的类图： 其中： NioEndpoint负责组装各部件 Acceptor负责监听新连接，并把连接交给Poller Poller负责监听所管辖的channel队列，并把请求交给SocketProcessor处理 SocketProcessor负责数据处理，并把请求传递给后端业务处理模块 在整个服务端处理请求的过程可以分为三个阶段，时序图如下所示： 阶段一：监听并建立连接 这一阶段主要是Acceptor监听新连接，并轮询取一个Poller ，把连接交付给Poller 阶段二： 监听客户端的请求 这一过程主要是让每个Poller监听所管辖的channel队列，select到新请求后交付给SocketProcessor处理 阶段三：处理请求 这一过程就是从多线程执行SocketProcessor，做数据和业务处理 于是乎我们发现抛开具体代码细节，Tomcat和Jetty在NIO的使用方面是非常一致的，采用的模式依然是下图： 来源： oschina 链接： https://my.oschina.net/u/59889/blog/49696

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 如何正确使用NIO来构架网络服务器一直是最近思考的一个问题，于是乎分析了一下Jetty、Tomcat和Mina有关NIO的源码，发现大伙都基于类似的方式，我感觉这应该算是NIO构架网络服务器的经典模式，并基于这种模式写了个小小网络服务器，压力测试了一下，效果还不错。废话不多说，先看看三者是如何使用NIO的。 Jetty Connector的实现 先看看有关类图： 其中： SelectChannelConnector负责组装各组件 SelectSet负责侦听客户端请求 SelectChannelEndPoint负责IO的读和写 HttpConnection负责逻辑处理 在整个服务端处理请求的过程可以分为三个阶段，时序图如下所示： 阶段一：监听并建立连接 这一过程主要是启动一个线程负责accept新连接，监听到后分配给相应的SelectSet，分配的策略就是轮询。 阶段二：监听客户端的请求 这一过程主要是启动多个线程（线程数一般为服务器CPU的个数），让SelectSet监听所管辖的channel队列，每个SelectSet维护一个Selector，这个Selector监听队列里所有的channel，一旦有读事件，从线程池里拿线程去做处理请求 阶段三：处理请求 这一过程就是每次客户端请求的数据处理过程