架构

关注「 IT老兵哥 」，赋能程序人生！既要低头赶路，又要抬头望天，科技是为人服务的，任何技术背后都有更深层次的考量，在本系列的第一篇文章中我们聊了微服务的本质，它是一种可以加速分工、促进合作的新协作机制。知其然，知其所以然，在第二篇文章中我们剖析了微服务为什么可以加速分工、促进合作，今天我们再接着来聊聊怎样开启微服务架构之旅。 微服务到底改变了什么，你知道吗？ 微服务，为什么可以加速分工、促进合作？ 1. 从前后端分离开启微服务改造 现在我们对微服务有了更深入的了解，也准备在构建新系统时采用这套新架构了，但它还是有些复杂度的，包括服务注册中心、统一配置中心、微服务网关、接入层网关、服务治理中心、调用链路追踪、分布式事务和分布式调度等众多组件。一口吃成胖子仅仅是一个美好的愿望，从单体式架构直接升级至全微服务架构，需要掌握这套全新的技术栈，对于缺乏前期铺垫的团队来说，学习曲线还是比较陡的，真正遇到的挑战往往超出想象的。 心理学对此有专门的研究，我们探索陌生世界的动力源于兴趣，而兴趣就是好奇心和正向反馈。如果我们刚开始就把目标设定的太高太远，在坚持努力了一段时间之后，还无法达成目标的话，那我们就接收不到正向反馈。久而久之，好奇心就会消磨殆尽，兴趣也就随之消失了。最靠谱的方式就是段带式进阶，将一个非常宏大的目标拆解成多个阶段性目标。在当前能力水平下

.NET 官方架构指南 Microservices and Docker Containers Web Applications with ASP.NET 官网地址：https://www.microsoft.com/net/learn/architecture 三层及多层架构 Multitier Architecture ASP.NET N-Tier Architecture Schema Visual Studio N-Tier Example 来源：https://dotnetdaily.net/featured/n-tier-architecture-asp-net 微软官方N-Tier 介绍：https://docs.microsoft.com/zh-cn/visualstudio/data-tools/n-tier-data-applications-overview 三层架构wiki https://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture https://en.wikipedia.org/wiki/Multitier_architecture 洋葱架构 Onion Architecture 四个洋葱架构（Onion Architecture）的原则：

想要的都拥有，失去的都释怀，2020鼠于你 内容目录 1，写代码容易吗 2， 设计模式 3，软件生命周期 4，技术业务架构 5，轮子 6，开源 7，真相 1，写代码容易吗 代码容易写，也不容易写。但做人不能一直太中立，那我选择好代码不容易写吧。 比如会写字，不一定能写出诗歌词赋。但你说写字难吗，对于牙牙学语时难的，对于现在的你，不难，只不过可能是自成一派，没那么好看。代码要能随着业务成长，方便做出拆分合并更新等，好的代码就要保证正确性前提下有更好的维护性。 2，设计模式 说到好代码一般都会涉及设计模式，有些经验的 程序员 已经不谈设计模式了，因为慢慢都习以为常了，他们开始向架构看去。 模式就是发现一种可识别的规律，比如色彩模式、简历模版也算。模式往往和抽象思维有关，分析事物共性，抽取事物共同的部分来帮助人们认识规律。设计模式就是对事物的重新定位整合来解决问题的一种模版一种套路。它是成熟的解决方案，解决类似的问题。 《设计模式：可复用面向对象软件的基础》一书中描述了23种设计模式。分为三类，创建型结构型行为型，其实都是对对象生命周期的再拆分，把创建过程独立出来，结构组合成功能，行为表达对象之间的交流，比如常用了观察者模式。当然设计模式也不是银弹，拆分会让架构变得复杂，但灵活性提高了，主要应对需求的变化。需求总会变，拆分让关注点分离，也慢慢架构产生了设计模式。 3，软件生命周期

见 https://www.cnblogs.com/skabyy/p/11396571.html 来源： CSDN 作者： bingshanzhu 链接： https://blog.csdn.net/bingshanzhu/article/details/103999884

原文: 记一份电网信息化建设企业信息分析平台规划 　　在项目建设过程中，应需求，其规划大数据信息化平台建设总体方案。 一、 总体原则 　　双创信息化平台建设遵循技术创新、应用创新，遵循国家、电网公司技术导向，充分考虑技术先进性，应用创新性。建设具备公司特色、具备创新特性、符合公司规范、满足公司发展及应用的一站式大数据信息化平台，提升公司大数据应用建设灵活性，充分发挥公司大数据资产价值。 　　双创信息化平台是在全业务统一数据中心上的完善、细化和提升，而又不对原架构造成指标考核影响。平台是技术、管理和应用的全面创新。整体平台独立部署，技术上借鉴全业务统一数据中心建设的技术积累成果，复用部分全业务统一数据中心在源系统数据接口为原系统减负，顶层架构遵循国网公司全业务总体设计，功能、模块、组件细化设计建设全新的、开放式平台，基于创新平台建设出彩大数据应用能够无缝迁移到全业务以向国网公司汇报。 　　创新平台定位为公司大数据分析应用创新建设环境，旨在支撑大数据分析应用建设开展，遵循国网公司数据不出平台的建设要求。 二、 总体方案 　　信息化板块总体框架规划遵循国网公司信息化建设标准体系、运维管理体系、安全管理体系。总体技术选型采用混搭技术架构，总体框架如下图： 信息化板块总体框架图 1 、基础设施 　　主要包括机房、网络、主机、存储、负载均衡设备、安全装置等。 2 、基础运维架构 　

由于软件系统的复杂性，一般人很难非常清楚的将整个系统理的很清楚，所以才会出现架构视图的概念，而架构视图出现的一个主要动力或者原则就是：分而治之。 分而治之有两种类型 1. 按问题深度分而治之，即先不把问题想的那么深入，那么仔细，要浅尝辄止。例如定义各个模块之间的接口就属于这种，先不考虑如何实现接口，只是定义模块之间进行通信时的契约。 2. 按问题广度分而治之，即先不研究整个问题，而是研究问题的一部分，分割问题，各个击破。例如采取 MVC 架构进行开发时，每一层都属于一个比较深入的部分。 软件架构应该采取哪种方式？ 所谓架构设计，是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕着系统分为哪些部分，各部分之间如何交互进行展开的。 所谓详细设计，则是针对每个部分的内部进行设计。 所以可以说对于架构设计，应该采取按照问题深度分而治之，关注的是系统的整体设计；而详细设计时应该采取按照问题广度分而治之，关注的是每个模块如何实现。 软件架构是团队开发的基础 一方面，架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节全部展开，从而有效的控制了‘技术复杂性’。 另一方面，因为架构中包含了关于各元素应该如何彼此交互的信息，所以可以把不同的模块分配给不同的小组分头开发，架构在中间扮演‘桥梁’和‘合作契约’的作用。 架构应该设计到什么程度？ 1.

本文节录温昱先生《软件架构设计》第8章 软件架构要做到什么程度，并将自己的理解在节录后做出描述。希望节录部分能给大家带来收获和感悟。并对我的理解部分提出建议和想法。 OK,让我们开始吧.解决软件架构到底要设计到什么程度? * 首先，对软件架构的设计程度问题展开探讨，得出基本结论。从对“分而治之”的讨论入手，说明软件架构是团队开发的基础，从而，软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度； * 之后，从问题入手，认识高来高去式架构设计的“症状”。主要分析实际工作中常见的架构设计不足的几种表现，找到要解决的问题； * 然后，说明如何解决架构设计高来高去、指导不足的问题； * 最后，结合案例，说明如何一步步地将架构设计落实到实处。 ------------------------------------------------------------------------------------- 8.1 软件架构要设计到什么程度 软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。 8.1.1 分而治之的两种方式 为什么要分而治之?简单说，就是问题太复杂了，超出了人们能够“一蹴而就”的范围。 面对一个复杂的问题，我们如何进行分而治之呢？策略有二： 一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。 二

近日，CODING 平台技术总监吴海黎参加了由 ECUG 社区举办的技术大会，与听众一同分享了 CODING 微服务架构的演进历程。让我们一起来欣赏精彩的演讲内容吧。 大家好！我是来自 CODING 的吴海黎，今天我给大家分享的内容是微服务拆分的实践，微服务几乎可以说是当下的一个主流架构，希望今天的分享能给大家落地微服务带来帮助。整个分享分为三个部分： 第一是单体架构的简介，第二是微服务架构落地方案，第三是 DevOps 之于微服务的重要性。 一、单体架构简介 虽然第一部分是介绍单体架构的主要痛点，但是还是应该跟大家分享一下，单体应用对于我们在业务早期，业务处理单一，团队规模较小，单体应用的中心化处理方案是能够降低团队的沟通成本，降低架构的复杂度，从而提高研发效率的这么一个架构。所以是否升级微服务架构，取决于我们所处的业务阶段和组织架构。介绍完单体架构的优势，我们一起来看看 CODING 微服务改造前的 Backend Service 是什么样的。 首先这个架构应该是 0.5 版本的微服务架构，可以看出这个架构有一部分服务已经是拆分成独立的微服务了，并且服务之间的注册和发现是依赖于 ETCD 去做服务发现与注册的事情。服务之间的通讯方式是 GRPC，我们选 GRPC 的原因是部分的服务是架在 GO 上面的，部分的服务是放在 Java 上面，所以我们需要跨语言的通讯方式。

从此重构 设计是如此重要，那么开发者的基本设计能力与素质又从何下手来培养呢？ 最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。然而，设计能力的提升绝非一朝一夕之功，软件开发中的设计大师，往往必须具备多年的修行方可称之为“架构师”。 一个在简历中轻描淡写的“ 10 年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意可言。在一个项目的实现过程中，逐渐了解什么是对象、什么是对抽象编程、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个软件项目，对于更多人来说是认识一种软件开发的科学流程。这种体验，才是难能可贵的经验。在设计的广义概念里，几个必需的概念是应该首先被了解和认知的，以排名不分先后的原则罗列，它们大概包括： · 面向对象 （ Object-Oriented ），关于面向对象没有必要重复嚼舌了，本书的第 1 章“ OO 大智慧”中对 .NET 的面向对象进行了有别于其他专著的介绍，除了以实例突出面向对象之思想大成，还以浓墨铺陈了 .NET 是如何在底层技术上来实现继承、多态和接口映射等机制，从而使读者可以更加有效和深刻地把握面向对象之精髓。 · 面向服务 （ Service Oriented ）， SO 至少是个时髦的话题， WCF 伴着 .NET 3.5 的发布，一个一统江湖的面向服务的基础架构横空出世

Netty 逻辑架构 Netty 采用了典型的三层网络架构进行设计和开发，其逻辑架构如下图所示： 1.Reactor 通信调度层 ：由一系列辅助类组成，包括 Reactor 线程 NioEventLoop 及其父类，NioSocketChannel 和 NioServerSocketChannel 等等。该层的职责就是监听网络的读写和连接操作，负责将网络层的数据读到内存缓冲区，然后触发各自网络事件，例如连接创建、连接激活、读事件、写事件等。将这些事件触发到 pipeline 中，由 pipeline 管理的职责链来进行后续的处理。 2.职责链 ChannelPipeline ：负责事件在职责链中的有序传播，以及负责动态地编排职责链。职责链可以选择监听和处理自己关心的事件，拦截处理和向后传播事件。 3.业务逻辑编排层 ：业务逻辑编排层通常有两类，一类是纯粹的业务逻辑编排，一类是应用层协议插件，用于特定协议相关的会话和链路管理。由于应用层协议栈往往是开发一次到处运行，并且变动较小，故而将应用协议到 POJO 的转变和上层业务放到不同的 ChannelHandler 中，就可以实现协议层和业务逻辑层的隔离，实现架构层面的分层隔离。 关键架构质量属性 1.高性能 性能是设计出来的，而不是测试出来的。下面来看Netty的架构设计是如何实现高性能的： 采用异步非阻塞的 I/O 类库，基于