架构设计

★简介 在实际的软件开发过程中，经常会碰到如下场景：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。 单单抽象出生产者和消费者，还够不上是生产者／消费者模式。该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。生产者把数据放入缓冲区，而消费者从缓冲区取出数据。大概的结构如下图。 为了不至于太抽象，我们举一个寄信的例子（虽说这年头寄信已经不时兴，但这个例子还是比较贴切的）。假设你要寄一封平信，大致过程如下： 1、你把信写好——相当于生产者制造数据 2、你把信放入邮筒——相当于生产者把数据放入缓冲区 3、邮递员把信从邮筒取出——相当于消费者把数据取出缓冲区 4、邮递员把信拿去邮局做相应的处理——相当于消费者处理数据 ★优点 可能有同学会问了：这个缓冲区有什么用捏？为什么不让生产者直接调用消费者的某个函数，直接把数据传递过去？搞出这么一个缓冲区作甚？ 其实这里面是大有讲究的，大概有如下一些好处。 ◇解耦 假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。将来如果消费者的代码发生变化，可能会影响到生产者。而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。 接着上述的例子

最近在做一功能不大、业务也不复杂的小众App，以往做App是发现自己从来没有考虑过一些架构方面的问题，只是按照自己以往的习惯去写代码，忽略了App的设计。本次分享主要包含一些开发App的小经验和技巧，来一次App开发与设计的分享。 先和分享下一下 实体类的设计与组织形式 实体类的组织 在做App开发的时候有很多的实体类，项目越复杂实体类就会越多，经过我的一番思考大致这可以将实体分为以下几大数： 面向数据库的 服务端返回的数据实体 用于渲染View的实体（使用Databinding） 一般情况下实体类的操作会经过以下步骤： App请求服务器获取数据 将数据存入数据库（可选） 渲染页面展示数据 现在的实体的产生只用在请求服务器数据的时候才需要新建，后续的数据库、页面渲染其实是可以使用一套实体： 先不说这样做的行不行，首先三个地方使用同一实体就会引起字段歧义比如服务器数据有Id、本地数据也有Id，那两个id字段就有冲突了不得不改字段名。 另一种情况渲染和数据本身并不会一一对应，有时候后端数据给的是一个纯数字而前端页面显示的是字符串两个都对应不上，强行放在一起会起来更多的问题。 所为实体类的的正确组织形式应该是： 相互隔离、互不干扰 ： 数据实体的在渲染之前都需要准备好，比如在ViewModel中将int型的数据转换成文本型的数据然后再使用Databinding＋页面渲染实体来渲染页面。

最近在做一功能不大、业务也不复杂的小众App，以往做App是发现自己从来没有考虑过一些架构方面的问题，只是按照自己以往的习惯去写代码，忽略了App的设计。本次分享主要包含一些开发App的小经验和技巧，来一次App开发与设计的分享。 先和分享下一下**实体类的设计与组织形式** ### 实体类的组织 在做App开发的时候有很多的实体类，项目越复杂实体类就会越多，经过我的一番思考大致这可以将实体分为以下几大数： * 面向数据库的 * 服务端返回的数据实体 * 用于渲染View的实体（使用Databinding） 一般情况下实体类的操作会经过以下步骤： 1. App请求服务器获取数据 2. 将数据存入数据库（可选） 3. 渲染页面展示数据  现在的实体的产生只用在请求服务器数据的时候才需要新建，后续的数据库、页面渲染其实是可以使用一套实体：  先不说这样做的行不行

上一篇 中我们介绍了为什么需要一个日志系统、为什么云原生下的日志系统如此重要以及云原生下日志系统的建设难点，相信DevOps、SRE、运维等同学看了是深有体会的。本篇文章单刀直入，会直接跟大家分享一下如何在云原生的场景下搭建一个灵活、功能强大、可靠、可扩容的日志系统。 需求驱动架构设计 技术架构，是将产品需求转变为技术实现的过程。对于所有的架构师而言，能够将产品需求分析透彻是非常基本也是非常重要的一点。很多系统刚建成没多久就要被推翻，最根本的原因还是没有解决好产品真正的需求。 我所在的日志服务团队在日志这块有近10年的经验，几乎服务阿里内部所有的团队，涉及电商、支付、物流、云计算、游戏、即时通讯、IoT等领域，多年来的产品功能的优化和迭代都是基于各个团队的日志需求变化。 有幸我们最近几年在阿里云上实现了产品化，服务了数以万计的企业用户，包括国内各大直播类、短视频、新闻媒体、游戏等行业Top1互联网客户。产品功能从服务一个公司到服务上万家公司会有质的差别，上云促使我们更加深入的去思考：究竟哪些功能是日志这个平台需要去为用户去解决的，日志最核心的诉求是什么，如何去满足各行各业、各种不同业务角色的需求... 需求分解与功能设计 上一节中我们分析了公司内各个不同角色对于日志的相关需求，总结起来有以下几点： 支持各种日志格式、数据源的采集，包括非K8s 能够快速的查找/定位问题日志

架构设计经验分享 架构的调整是否必须按照上述演变路径进行 不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。 对于将要实施的系统，架构应该设计到什么程度 对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。 服务端架构和大数据架构有什么区别 所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力

架构设计 是一个非常大的话题，不管写几篇文章，接触到的始终只是冰山一角，更多的是实践中去体会。这篇文章主要介绍面向对象OO、面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用。 架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。 这三个维度分别为面向对象、面向方面、面向服务。 这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。 面向对象 面向对象技术最初是从面向对象的程序设计开始的，它的出现以上世纪60年代Simula语言为标志，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前思想的重新注解。 上世纪80年代中后期，面向对象程序设计逐渐成熟，被计算机界理解和接受，人们又开始进一步考虑面向对象的开发问题。直到现在，面向对象已经成为一种非常流行的编程方式，以及软件设计的架构。 面向对象提出有三个主要目标:重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。 在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。 面向方面 面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。

Linux系统运维与架构设计-VMWare WorkStation安装CentOS7.7 Linux系统运维与架构设计 3.1 Linux系统运维环境概述 CentOS系统通常运行于服务器之上，而如果想要在个人电脑上使用CentOS，只需要准备系统镜像，国内用户可以去阿里云镜像站下载， 目前最新的CentOS7系列版本为CentOS7.7,当然目前已经有CentOS8， 但是VMWare WorkStation15.5不支持CentOS8 因此选用CentOS7.7。而且CentOS7系列相对于CentOS8系列更加成熟、稳定，是目前主流的CentOS版本。 如果个人计算机是Windows可以使用VMWare WorkStation来安装CentOS7.7,如果个人计算机是Mac,可以选择Parallels Desktop来安装CentOS7.6。 为什么使用WMWare WorkStation或者是Parallels Desktop来安装CentOS而不是直接安装在个人计算机上呢？这里有两点原因，首先是CentOS主要用于服务器操作系统，不适用于个人办公，还有就是通过使用VMWare WorkStation或者是Parallels Desktop上使用CentOS，和直接安装在个人计算机上几乎没有区别。即使虚拟机宕机，也不会影响宿主机(Windows10或则是macOS10.15

这是敏捷开发一千零一问系列的第十篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 问题 总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？ 方案 之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。 方案1：开发人员全体参与架构设计 敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。 一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保不发生歧义，因此做架构的人和写代码的人在一定程度上融合一下，能大量减少不必要的架构设计，尤其是某些细节。 二方面，文档或设计本身不是工作产品，在上面投入太多的工作量，极有可能是浪费而非保障。 当然问题是：哪些人有能力做架构？ 这个问题如果换成：哪些人可以开一家新的世界500强企业？答案是“大学在校生”（IT界最近的世界500强多数都是在大学里边成立的）。所以同样是这些人，一样能做架构，只是看怎么做了。 方案2：用师徒团队搭建全民架构团队 如果没有专门的架构人员和编码人员，那么最好的结构就是师傅们做架构，同组的徒弟们将其实现为编码。 “这不也是分工吗？”是的

这是敏捷开发一千零一问系列的第九篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 问题 总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？ 这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。 方案 最早想写成方案1、方案2，但感觉有点像说是有不同的很多并行方法，之后又改成步骤1、步骤2，又有点把事线性化了。 现在干脆写回成方案123吧，总之越往后的越终极一些，也越难以一步到位。 方案1：Sprint0 对于长期的项目，常常引入“Sprint0”的概念。 Sprint0就是在开始不断开发功能的众多Sprint迭代前，先做一个准备工作，大约持续一个迭代的周期。 准备工作的内容五花八门，从团队组成，项目范围，到这里说的架构设计。有些团队每过一段，尤其在发布了重要的版本后，都会重新开一个Sprint0，来分析下一个版本的架构设计。 这样就可能出现几种不同的迭代变形，最左边的是最轻量级的（周期短的、架构不重要的），最右边的则相反。 Sprint1 Sprint2 ... SprintN Sprint0 Sprint1 Sprint2 ... SprintN ... Sprint0 Sprint1 Sprint2 ... SprintN

概念 “4+1”视图，是指从5个不同视角来描述软件体系结构。 “4+1”分别指： 逻辑视图 过程视图 物理视图 开发视图 场景/用例 视图 逻辑架构的描述可以围绕前四个视图进行组织，然后结合用例或场景进行说明，形成第五个视图。 每个视图只关心系统的一个侧面，5个视图结合起来，才能反映系统的全部内容。 关于视图 软件设计可以从不同的概念角度进行描述和记录，这些角度通常被称为视图。 “视图表示软件体系结构的一部分，它显示软件系统的特定属性” 不同的视图涉及与软件相关的不同问题。 总之，软件设计是由设计过程产生的多方面的产物，通常由相对独立的正交视图组成，可以结合建筑视图理解。 逻辑视图 当使用面向对象的设计方法时，逻辑视图对应设计的对象模型，常用描述方法有UML类图、E-R图。 逻辑架构主要支持功能需求，即系统应该为用户提供什么样的服务。 系统被分解成一组关键抽象，以对象或对象类的形式从问题中表述。 类的设计遵循抽象、封装和继承的原则，这种分解不仅是为了进行功能分析，也是为了理清系统各个部分的通用机制和设计元素。 过程视图 过程架构关注设计的并发和同步方面，考虑了一些非功能性需求，比如性能和可用性。 过程视图可以在几个抽象层次上进行描述，每个抽象层次处理不同的关注点： 在最高层次上关注进程，进程分布在由LAN或WAN连接的一组硬件资源上，作为一组独立执行的通信程序逻辑网络。