应用架构

PX-Autopilot: 自动化的存储容量管理，节省一半的云存储成本 不少客户都在使用K8S来管理容器，并且通过Portworx来管理容器存储。虽然云原生的方式让我们获得了更大的自动化和灵活度，许多客户在容器下层的基础架构层的扩展性方面，仍然有一定的局限。K8S和Portworx能够自动化部署容器应用，但是这些应用所基于的基础架构还无法通过自动化的方式进行扩展。DevOps团队还经常被要求去做基础架构投资成本收益的财务分析，并增加财务管理手段来降低成本和让成本更具备可预测性。当基础架构被转移到公有云后，成本管理就成为更加重要的方面，不少用户在公有云上的成本甚至高于他们原有的本地部署架构的成本。Portworx新发布的PX-Autopilot能够对存储基础架构进行更加有效的运营管理，并且降低一半的存储成本。 PX-Autopilot: 自动化的存储容量管理 PX-Autopilot让客户能够自动化的扩展存储， 不仅是扩展某个容器化应用所属的存储（通过PVC的扩容） ，还可以对基础架构层的存储池进行扩容。Portworx2.3.1最新版本中，已经包含了PX-Autopilot。通过PX-Autopilot，客户能够更加方便的构建企业级自服务K8S应用和数据管理能力， 不论是在本地部署，私有云，还是公有云中 。 我们的目的是帮助客户： 大幅简化为容器应用做存储扩容的操作

RPC RPC(Remote Procedure Call) 广义上的RPC RPC（架构）框架 RPC框架原理 PRC架构组件 PRC架构调用过程 常见的RPC框架及分类 常见的RPC 框架的比较 RPC协议 MVC架构、RPC架构、SOA架构、微服务架构区别 单体架构 MVC(Model View Controller) 多服务架构 RPC(Remote Procedure Call)远程过程调用 SOA(Service Oriented Architecture)面向服务架构 微服务架构(轻量级的服务治理方案) RPC(Remote Procedure Call) 远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 个人觉得单纯的讲RPC 是没有意义的。 RPC应该被分为广义上的RPC ,RPC框架，RPC协议（后2个暂且称之为狭义的RPC） 广义上的RPC 所谓广义RPC 根据定义 通过网络调用远程计算机上的服务即可称之为RPC 。所以任何符合该说明的都应该属于RPC。包括常见的web服务个人觉得其实也可以理解为RPC. RPC（架构）框架 RPC框架原理 PRC架构组件 一个完整的RPC架构里面包含了四个核心的组件，分别是Client，Client Stub，Server以及Server Stub，这个Stub可以理解为存根。

1、Flutter架构图 （1）、Framework层 Framework使用dart语言实现，包括UI，文本，图片，按钮等Widgets，渲染，动画，手势等。此部分的核心代码是flutter仓库下的flutter package，以及sky_engine仓库下的 io, async, ui(dart:ui库提供了Flutter框架和引擎之间的接口)等package。 （2）、Engine层 Engine使用C++实现，主要包括:Skia, Dart 和 Text。 Skia是开源的二维图形库，提供了适用于多种软硬件平台的通用API。其已作为Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他众多产品的图形引擎，支持平台还包括Windows, macOS, iOS，Android，Ubuntu等。 Dart 部分主要包括:Dart Runtime，Garbage Collection(GC)，如果是Debug模式的话，还包括JIT(Just In Time)支持。Release和Profile模式下，是AOT(Ahead Of Time)编译成了原生的arm代码，并不存在JIT部分。 Text 即文本渲染，其渲染层次如下:衍生自 Minikin的libtxt库(用于字体选择，分隔行)

http://www.cnblogs.com/seaky/archive/2011/04/06/1982533.html 在深入分析MVC和MVP之前，我们有必要回顾下经典的三层架构。分层是计算机学科解决许多问题的法宝。在企业应用和互联网应用中，分层架构得到了非常广泛的应用。3层架构是各种层架构的基础，3层架构简单描述如下: 展示层 :展示层有两个职责 1负责展示业务数据 2提供用户输入的接口 业务逻辑层 :业务逻辑层的职责是接受展示层的输入，并经过业务处理逻辑，返回业务数据。 数据访问层 :数据访问层提供系统数据的存取服务。 从架构到实现是存在一些"距离"的，架构的实现是要基于应用场景，实现方案也有所不一样。 本文考虑两种应用场景来讨论MVC和MVP: 第一是c/s架构，也就是所谓的胖客户端，像RIA属于这类。Flex，ajax等技术都可以归结到RIA，手机APP，winform连接到远程服务的应用都可以归结这一类。 第二是b/s架构(某些web程序部分的利用了ajax，排除利用ajax的这部分)，也就是瘦客户端，b是指浏览器，在b/s架构中http协议是客户端和服务端通信的唯一协议，而且是通过浏览器来展示数据的。 基于层的架构的实现中的一个问题就是层与层之间如何通信，以及如何在层间传递数据。 首先看看数据访问层和业务层之间的通信和数据传递。 (注意， 数据访问层不保存持久数据

在 微服务的基建工作 中提到过，在云原生、微服务时代，如果还是手动修改服务地址，是几乎不可完成的工作，需要一种机制完成自动上报和获取服务地址的支撑组件，可以保障服务的快速上线和下线，这就是服务注册/发现组件。 为了表述方便，从系统规模定义几个阶段： 巨型应用架构时期：很多应用都是一个巨型服务，一个应用包含所有功能，部署在小型机和大型机上，或者直接部署在物理服务器上。 单体架构时期：应用体量缩小，服务增多，而且出现虚拟化技术，物理服务器被连接成虚拟化平台，应用部署在虚拟机中。 SOA架构时期：应用通用功能逐渐沉淀，业务应用借助沉淀的通用组件逐渐解耦，微服务的很多组件也是从这个时期开始成型。 微服务架构时期：这个时期承接模块化时期，甚至有一种说法是微服务只是SOA的一种特殊形式。系统进一步解耦，根据业务角色不同，应用以业务为分界，缩小为业务单元。 函数架构时期：应用进一步分割为函数，实现serverless架构，不需要具体的服务器概念，只需要执行函数的服务即可。目前来看，这个时期是比较理想的时期，因为不同人相互协作定义的函数，可能重复或者冲突，不利于架构的演进。 随着大家对在微服务或者函数架构中趟坑，很多人开始提出回归单体应用架构，这应该也是架构螺旋进步的一种方式。 在微服务中，还有一种角色是根据调用关系定义的： 客户端服务（简称客户端）：调用其他服务的实例 服务端服务（简称服务端）

WebLogic管理控制台 WebLogic服务器提供了一个健壮的基于Web 的工具——管理控制台，它是执行上述任务的主要工具。通过管理控制台，你可以访问WebLogic管理服务。管理服务实现了 Sun的Java管理扩展标准（JMX），它是WebLogic 资源管理的基础。 你可以用管理控制台来配置资源的属性，分发应用及组件，监控资源的使用情况（如服务器负载，Java虚拟机的内存使用情况以及数据库连接池的负载），查看日志消息，终止服务器，以及执行其它管理任务。 域、管理服务器与受管服务器 作为一个单元来管理的并相互关联的一组WebLogic服务器资源被称为域。一个域可以包含一或多个WebLogic服务器，还可以包含WebLogic服务器集群。域的配置使用扩展标记语言（XML）定义。install_dir/config/domain_name 目录中的config.xml 文件定义了域的配置，install_dir是WebLogic Server软件的安装目录。 域是一个完备的管理单元。向域里分发应用的时候，该应用的各组成部分只能分发到域之内的服务器上。如果域中包含集群，那么集群中的所有服务器都必须属于同一个域。 运行管理服务的WebLogic服务器称为管理服务器。管理服务集中管理并监控域的所有资源。 如果要对某个域执行管理操作，该域的管理服务器必须处于运行状态。 一

引言 在跟同行交流的时候，常常有人这样问：中台不就是微服务吗？都是以服务化的方式对外提供能力，老瓶装新酒嘛，炒作概念而已。 这种说法实际上混淆了中台与微服务的定义，要说清楚这个问题，就要先了解，什么是中台？什么是微服务？中台和微服务之间有什么样的关系？ 01 中台是什么？ 1.1 中台的定义 来自阿里官方的定义，“ 企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。 ” 阿里的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。 共享业务单元的划分原则其实不是可以简单掌握的，要综合考量设计、运营和工程因素，尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。 阿里在划分中台时非常重视其业务价值和基于业务的设计，而且有业务架构岗位，每个共享单元都有业务架构师。但总体来讲，其业务架构仍然是领域性的。 1.2 代表企业 企业中台最早是由阿里在2015年提出的，即逍遥子张勇倡导的“大中台，小前台”战略、“数据+业务双中台”等等。 随后BAT、TMD纷纷效仿，提出了各家的中台战略

今天给大家带来一篇自己翻译的干货《软件架构师之路》。本周Github上升很快的项目。其内容对致力于成为软件架构师（不论前后端）的同学应该都会有极大的帮助。 项目地址: 中文地址 https://github.com/gamedilong/SoftwareArchitect-CN 原文地址 https://github.com/justinamiller/SoftwareArchitect 如果有看完英文原文，发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR，如能够对大家起到一定的帮助也欢迎star 内容 什么是软件架构 软件架构的层次 软件架构师的典型工作内容 软件架构师的重要技能 架构师的技术路线图 相关书籍 什么是软件架构? 软件架构师是一名软件开发专家，他可以进行高层设计选择并决定技术标准，包括软件编码标准，工具和平台。 (出处: 维基百科:软件架构师) 软件架构（architecture）是一个系统的基本组织，由其组件、它们之间的相互关系和环境以及决定系统设计和演化的原则来表示。 (出处: 软件架构手册) 软件架构的层次 软件架构可以被抽象的分为几个层次，不同的层次对技能的要求不同。对层次有很多不同的划分，我最喜欢如下这三种划分: 应用级 : 最低层次的架构。聚焦单个具体的应用。 非常注重细节, 底层设计。 沟通仅限入单个开发团队。 解决方案级 : 中级别的架构

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

https://blog.csdn.net/weixin_45494421/article/details/98760782 概要：常见的分布式文件系统有GFS、HDFS等，也有新兴的基于区块链IPFS/Filecoin等。有的广泛应用，有的开始挑战，有的是闭源，有的开源。在不同的领域和不同的计算机发展阶段，它们都对数据存储起到了各自的作用。那么这些分布式文件系统都有什么优缺点？我们应该怎样选择适合自己的解决方案？ 一、HDFS：被雅虎开源的分布式文件系统 Hadoop分布式文件系统（HDFS），是一个分布式、可扩展的Hadoop框架，具有高容错、低成本部署优势。HDFS提供对应用程序数据的高吞吐量访问，适用于具有大型数据集的应用程序。HDFS最初是作为Apache Nutch网络搜索引擎项目的基础设施而构建的，现在是Apache Hadoop子项目。 HDFS如何工作？HDFS支持计算节点之间的数据快速传输，文件系统多次复制或复制每个数据，并将副本分发到各个节点，将至少一个副本放在与其他服务器机架不同的服务器上。因此，崩溃的节点上的数据可以在群集中的其他位置找到。这可确保在恢复数据时继续处理。这使得HDFS高容错性。简单来说，HDFS将文件拆分为块，并将它们分布在集群中的节点上。 架构分析：HDFS采用的是主/从架构（master/slave ）