架构设计

一、从第十一章中： 细化架构的故事 中总结摘录出以下一部分： 　　架构设计仅仅进行到概念架构层面，对支持团队的并行开发而言是远远不够的；对于多视图方法，要有意识地调整、扩充、改进经典方法以符合实践的真正需要。 　　从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略 ; 再进行细化架构的设计，以保证为开发提供足够的指导和限制。 二、从第十二章中： 什么是 Refined Architecture 中总结摘录出以下一部分： 　　架构设计是一门解决复杂问题的实践艺术，于是，以分而治之为思想核心的多视图方法必不 可少。 　　而多视图方法有两个方面的实际意义：利于思考（因为分而治之的思维方式）；便于交流（因为在一定程度上分离了涉众关注点）。 　　一 种优秀的多视图方法，应该能够比较完善地覆盖架构设计的各项工作内容，且将每项工作内容明确地、有理有据地、一目了然地划归到不同架构视图中去。 三、从第十三章中： 逻辑架构 中总结摘录出以下一部分： 　　一线架构师最缺的不是理论， 也不是技术，而是位于理论和技术之间的 “ 实践策略 ” 和 “ 实 践套路 ”。就划分子系统这个架构师必做的工作而言，其实践策略可归纳为 3 种 : 分层的细化；分区的引入；机制的提取。 　　逻辑架构设计的 10 条经验要点：划分子系统 : 分层的细化；目划分子系统 : 分区的引入；划分子系统 : 机制的提取

目录 什么是微服务模式 单体结构的历程 单体地狱的银弹-微服务架构 扩展立方体和服务 微服务架构的好处和弊端 优点 大型的复杂应用程序可以持续交付和持续部署 每个服务都相对较小并容易维护 更好的容错性 更容易实验和采纳新的技术 弊端 服务的拆分和定义是一项挑战 分布式系统带来的各种复杂性 开发者需要思考到底应该在应用的什么阶段使用微服务架构 服务的拆分策略 识别系统操作 创建抽象领域模型 定义系统操作 根据业务能力进行服务拆分 从业务能力到服务 根据子域进行服务拆分 上帝类的处理 什么是微服务模式 随着网络基础设施的高速发展，以及越来越多的个体接入互联网，在考虑构建支持海量请求以及多变业务的软件平台时，微服务架构成为多数人的首选。微服务架构的出现时服务事物发展规律的：当问题足够大，有足够多的的不确定因素时，人们习惯于把大的问题拆分成小的问题。通过分割，抽象和重用小而可靠的功能模块来构建整体方案。但是当这些小的，可重用的部分多来越多的时候，又会出现新的问题。再相似的阶段，人们遇到的问题也是相似的，这个时候人们需要一些共识，需要用一些通用的词汇来描述问题以及解决方案，这也是人们知识的总结，微服务模式就是这样的总结和概括，是一种可以通用的共识，用于描述微服务领域的中的问题及解决方案。 单体结构的历程 在企业发展的初期，应用程序相对较小，所有的代码运行在一个应用程序中有以下好处

介于这段时间的学习，MVC 和 Entity Framework 再加上自己对框架这部分的理解，弄了这么个Demo，希望大家能给点意见，一起讨论讨论。本章中没有多么高深的理论知识，只是个人对于架构的理解，加上MVC 和 EntityFramework，可以说是个整体的部分 先贴下我的项目的分布图： 整个项目主要采用三层架构，面向接口的编程方式。 界面层：User Interface CinDou.Web主要放我们的Web页面， CinDou.Route主要放置MVC中Controller， 这里我采用把Controller分离出来。个人考虑的原因是：项目比较清晰，职责比较单一。 逻辑层：Business Logic Layer CinDou.BFactory 是逻辑工厂层，用于创建逻辑层的接口，便于界面层调用。 CinDou.IBLL 逻辑接口层 CinDou.BLL 逻辑业务层 主要负责逻辑层中的业务。 CinDou.Model 逻辑业务类 数据库层：Data Accss Layer CinDou.DFacoty:数据工厂层，用于创建数据库层的接口，从而让逻辑层调用 CinDou.IDAL : 数据库接口层 CinDou.DAL : 数据库持久层 CinDou.EFramework: Entity Framework层 工具层：ToolKit CinDou.Tools

第5章 数据分析 5.1 日志收集 5.1.1 inotify机制 通过inotify机制，能够对文件系统的变化进行监控，如对文件进行删除，修改等操作，可以及时通知应用程序进行相关事件的处理。 5.1.2 ActiveMQ-CPP C++接口的消息订阅系统 5.1.3 架构和存储 数据需要经过inotify客户端，经由ActiveMQ进行转发，通过storm进行实时处理，再存储到Mysql、HDFS、Hbase或者Memcache这些存储系统当中，最后再进行深度分析或者实时的展现 5.1.4 Chukwa 5.2 离线数据分析 5.2.1 Hadoop项目简介 Hadoop：HDFS，MapReduce，Zookeeper、Hbase、Hive、Pig、Mahout 5.2.2 Hadoop环境搭建 略 5.2.3 MapReduce编写 5.2.4 Hive的使用 略 5.3 流式数据分析 5.3.1 Storm的介绍 1、Storm是一个开源的分布式实时计算系统，可以简单，可靠地对大量的流式数据进行分析。 2、通过zeroMQ作为底层的消息队列，可以保证消息能得到很快的处理 5.3.2 安装部署storm 略 5.3.3 storm的使用 5.4 数据同步 在线的OLTP 或 日志系统-----OLAP系统----->多维度复杂的数据分析和汇总操作 5.4.1 离线数据同步 1

依赖老旧系统方案设计 新建一个系统，该系统对老旧系统有依赖，也可能会相互依赖时，如何设计 整个考试模块从开始到现在，整个交互（系统功能提供着）调整4次，可谓变更之频繁。那为什么会产生这么多次变更呢，最主要的原因是没有一个整体的控制者，因为每一种方案的产出要考虑，几个方面：用户体验、未来规划、开发成本、工期要求，在考试这个事情上，用工和质检的合作是必然的趋势。但在协作模式上总是出现问题。从第一版的交互方案评审，业务的就产生新的功能要求，想页面文案啊，考试的具体功能啊，这些功能的实现与之前写的协作模式是违背的。所以一次次推翻了之前的方案。主要原因在于协作的方式过于耦合，职责不清晰，导致无法合理扩展。而今天的方案，恰好是这职责清晰的，满足业务功能的。我认为是可行的。符合设计模式。 来源： https://www.cnblogs.com/xiaogangfan/p/11365337.html

CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

3 月，跳不动了？>>> 1 基本概念和目的 架构设计的目的是为了解决系统复杂度带来的问题，并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出实际业务实际情况的复杂点，然后有有 针对性地解决问题 ，即： 有的放矢，而不是贪大求全 。 在实际情况中，不一定每个系统都要做架构设计，需要结合实际情况。有时候最简单的设计开发效率反而是最高的，架构设计毕竟要投入时间和人力，这部分投入如果用来尽早编码，项目也许会更快。 2 架构设计复杂度来源 高性能 高可用 可扩展性 低成本、安全、规模 3 架构设计三原则 合适原则 GFS为何在Google诞生，而不是在Microsoft诞生，其中Google有那么庞大的数据是一个主要因素，而不是因为Google的工程师比Microsoft的工程师更加聪明。 真正优秀的架构都是企业 在当前人力、条件、业务等各方面约束条件下设计出来的 ，能够合理地将资源整合一起并发挥出最大功效，并且能迅速落地。这也是很多BAT出来的架构师到了小公司或者创业团队反而做不出成绩的原因，因为没有大公司的平台、资源、积累，只是生搬硬套大公司的做法，失败的效率非常高。 简单原则 无论是结构的复杂性还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单方案和复杂的方案都可以满足需求，最好选择简单的方案。《UNIX编程艺术》总结的KISS（ Keep It

3 月，跳不动了？>>> CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

现在的软件系统越来越复杂，当然相应地，架构的作用也越来越明显。作为开发人员，我们每天都在和架构打交道，在这个过程中，对于架构也经常会产生各种各样的问题： 什么是架构？架构都有哪些分类，分别解决什么问题呢？ 怎样才是一个好的架构设计？我怎么才能成长为一名优秀的架构师呢？ 这些问题涉及我们对架构的认识，也是学习和运用架构的开始。所以，今天，我们就来深入地分析架构的实质，让你能够透彻地理解它。 架构的本质 物理学中有个很著名的“熵增定律”：一个封闭系统，都是从有序到无序，也就是它的熵（即混乱程度）会不断地增加，最终系统会彻底变得无序。 这个理论放在软件系统的演化上，也是非常适用的。 一方面，随着业务需求的增加，我们会往系统里不停地添加业务功能；另一方面，随着访问量的不断增加，我们会不断通过技术手段来加强系统非业务功能。如果事先不做良好的设计，随着时间的推进，整个系统野蛮生长，就会逐渐碎片化，越来越无序，最终被推倒重来。 不过，自然界中的生物可以通过和外界交互，主动进行新陈代谢，制造“负熵”，也就是降低混乱程度，来保证自身的有序性，继续生存。比如，植物通过光合作用，把光能、二氧化碳和水合成有机物，以此滋养自己，延续生命。对于软件系统，我们也可以主动地调整系统各个部分的关系，保证系统整体的有序性，来更好地适应不断增长的业务和技术变化。这种系统内部关系的调整就是通过架构实现的，所以

引言 时间如梭，娃都可以打酱油了。 转眼间第一个五年计划，已过了一半。 年终总结是个打脸的好地方，曾经夸下的海口，有的真的成了海口。 所幸，一切都在按好的方向发展。但乐观背后容易忽略潜在的问题，所以，在2020来临之际，是时候对2019做个具体的回顾，并对来年做个具体的展望。 谈成长 那就先从收获开始讲起吧。 成功续任微软最有价值专家。 离开工作4年的老东家金蝶，前往自己看好的物联网行业发展。 码字3万+，写博10篇。 开始尝试进行架构设计，并应用微服务技术栈 第一次受企业邀约，前往厦门做技术分享 作为讲师，参加Microsoft Ignite The Tour 大会 这一切的收获得益于我坚强的后盾 —— 双方父母的支持，老婆的理解与督促，还有我那调皮捣蛋的小家伙给我源源不断的动力，所以感谢我至亲至爱的家人！也感谢一路走来给予我帮助、指引我方向的每一位可爱的人。 谈工作 今年做出了一个艰难的决定，就是跳出自己的舒适圈，从工作4年的老东家辞职，加入到一家物联网创业公司。这里十分感谢张队的引荐，才有一个好的落脚点，才得以实施自己的技术抱负，才得以转型自己期望的技术栈，从传统的.NET 后端转移到.NET Core 全栈开发。真正的去实践微服务，玩转K8S。当然，也得益于前期的理论知识的积累。 加入新公司，是机遇，是挑战。 记得入职后的第二天，就紧急前往武汉出差