架构

数据层应用程序( D ata-tier A ppli C ation，简称 DAC )是一个数据库逻辑架构的管理工具，DAC定义了用于管理单个SQL Server数据库对象（包括table，view，以及实例级别对象login等）的元数据。使用DAC，用户能够很方便地将数据库打包成一个DAC package文件，后缀名是DACPAC，只需要简单的操作，就能将数据库部署在其他服务器上，类似于数据库的完整备份，只不过dacpac文件不包含数据，只包括数据库对象的元数据，用户使用这些元数据能够创建一个空的，一模一样的数据库。使用DAC，用户也能够将数据库对象的架构和数据打包成一个backup package文件，后缀名是bacpac。使用该文件，用户能够在另外一个SQL Server实例中创建新的数据库，新的数据库含有原始数据库的所有数据和架构（Schema）信息。 通过DAC实现数据库的架构迁移，DACPAC文件主要用于部署数据库的架构（Schema），创建产品数据库的测试环境，对新业务需求进行代码逻辑测试；而BACPAC文件在逻辑上等价于数据库的完整备份，主要用于数据库架构和数据的整体迁移，BACPAC文件支持EXPORT操作，用于备份数据库，IMPORT操作用于在目标服务器上创建新的数据库，类似数据库的还原操作。 一，使用DAC实现数据库的架构迁移 完整的架构迁移操作，分为抽取

入职了新公司，使用了Docker和K8s，需要有一个基础的了解，对网络上相关信息进行了简单总结。 一Docker 1简介： Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。 2功能： 虚拟化解决了应用运行环境的复杂，硬件管理的问题，提供可移植性。 3架构： Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。 Docker 客户端(clients)会与 Docker 守护进程进行通信。 Docker 守护进程(daemon)和容器运行在一台主机上。用户并不直接和守护进程进行交互，而是通过 Docker 客户端间接和其通信。 Docker 容器和文件夹很类似，一个Docker容器包含了所有的某个应用运行所需要的环境。每一个 Docker 容器都是从 Docker 镜像(image)创建的。 Docker仓库(repsitory)用来保存镜像。 4应用场景： 1)提供一次性的环境 2)提供弹性的云服务 3)组建微服务架构 二K8s 1简介： 全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度

CC1310架构及工作原理 CC1310组成部分： 主MCU ：搭载的是ARM Cortex-M3，它作为CC1310主要的操控部份，包含的是RTOS和对底层外部接口的ㄧ些drivers，同时客户的应用程序也跑在这个部分； RF核 ：顾名思义就是和射频相关的，它包含的是射频的一些接口，主MCU通过发送命令的方式可以控制射频进行工作，同时RF核会返回射频工作的结果给主MCU； Sensor Controller Engine ：CC1310独有的一个部份，它可以独立于主MCU工作，主要操控的是外部传感器和一些接口，可以自己做一些小的编程； Peripherals ：就是一些外设，包括一些GPIO UART的口AES加密、Timers相关的； Sensor Controller和整个的这个系统如何工作以及整个系统是如何达到低功耗的： 举个例子，CC1310需要完成的工作是以一秒的频率，从外部的传感器获取数据，然后把这个数据通过AES加密最后发送出去的； 首先，主MCU、RF Core和外设全部都是关闭的，Sensor Controller Engine独立于这三个部分独立工作，从外部的传感器以一秒的频率进行采样，Sensor Controller Engine它可以独立编程，那么在编程逻辑里面我们加入了对传感器数据的判断，如果传感器的数据高于阈值，那么我们就唤醒主MCU

一、亚马逊的架构规定 　　最早实践分布式服务化架构思想的公司应该是亚马逊，它早在 2002 年就颁布了下列架构规定，这应该就是 AWS（Amazon Web Service）出现的基础： 　　1. 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。 　　2. 团队间程序模块的信息通信，都要通过这些接口。 　　3. 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链接别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。 　　4. 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。 　　5. 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。 　　6. 不这样做的人会被炒鱿鱼。 　　前面提到过，分布式系统架构会带来很多问题，譬如： 　　1. 一个线上故障的工单会在不同服务和不同团队中转过来转过去； 　　2. 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都做好配额和限流； 　　3. 监控和查错变得更复杂

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一直以来，作为一名软件工程师，都十分向往“架构师”的名号，也一直奋斗在通往“架构师”的路上。但如果要是问他们： 什么是架构师？往往每个人回答的都千奇百怪 ，也就是说在每一个人的心里对架构师的认识都互不相同。有的人说，架构师要掌握很多的技术。也有的人说，架构师不必到细节，要宏观把控。还有的人说，架构师要有超强的预知能力。等等。就如同盲人摸象，“架构师”一词太大、太笼统了，如果仅是站在自己认为的角度来看，很难准确定义出“什么是架构师”。 其实“架构”不是软件行业的专有名词，在软件行业很早之前，架构就已经存在了，比如：建筑行业等。所以“架构”并不是局限在某一行业中，反而它存在于整个人类社会的高效协作之中。要真正的去理解架构，并不能局限于软件行业之中，当然了后续会重点讲述软件行业中的架构。 面对“架构”一词，空杯心态，从起源开始分析“架构”的诞生。为何空杯心态，暂时放弃之前自己认为对架构的认知，从“架构”由无到有的诞生角度来认知，之后再和自己之前的认知，进行碰撞纠正吧。 本文将先从“人”、“组织”、“社会”三个方面来讨论架构为何产生、架构为何物、应该如何去做架构？最终会在“软件”行业方面，根据对架构的认知，来实施架构的落地。 从远古谈起 在远古早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 上一篇文章 《架构由术至道的转变（1）》 已经从“人”、“组织”、“社会”三个方面讲述了架构的起源，为什么会产生架构，产生架构的动力条件，并分析了如何可以更好的做好架构，比如：概念认知、问题识别、架构切分，这些都是做好架构最核心、最实用的思维手段，相信真正理解了这些道的含义，再到软件行业进行架构实践，会更加的游刃有余。 其实软件行业也是社会的一部分，社会是由人组成的，自然架构最终是解决人的问题。有人的地方，便有了江湖，林子大了啥鸟都有，江湖中也便起了纷争，其实归根结底还是人对自己利益最大化的诉求。不过在此强调下，人对利益最大化的诉求，不是产生架构的必要条件，产生架构必要条件可查看 《架构由术至道的转变（1）》 。 好了，那就让我们来看下，在软件行业中，架构又是为何产生，又是解决人的什么问题，最后再讨论下，软件行业的架构是如何做的。 首先，我们要确认什么是软件 软件的历史，实际上可以说是用机器模拟人的历史 。不管大家（包括在这个历史过程中的参与者）有没有意识到，我们都有意无意的在计算机上模仿人类的行为。 人们越来越愿意把原来只有人才能做的事情，交给计算机来做。结果就导致软件越来越丰富，能够做的事情也越来越多，成本也越来越低。可以这么说， 成本是我们为什么采用软件的主要动力，可以节省大量的人员培训，减少雇员的数目

来源： CSDN 作者： 学亮编程手记 链接： https://blog.csdn.net/a772304419/article/details/103643798

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 症前兆 记得有个朋友跟我讨论过这样的一个问题，说到他刚刚学习 接口 和 虚基类 的相关知识时觉得很迷茫，不知道什么时候该用接口，什么时候该使用虚基类。后来慢慢地发现接口能做的事情，虚基类也能够实现，甚至有更多的特点。再后来就慢慢地放弃了接口，把所有的设计和实现都采用虚基类来替代。不能说我这个朋友这样的处理有错，但是就我个人对接口和虚基类的理解来说，这样的做法是有不妥的地方。 症分析 所谓的 接口 简单的来说就是个“门口”，而这个"门口"是安装在某个模块或者服务上，其目的就是为了让外面的世界通过这个“门口”可以访问到模块上的功能或服务。由于是跟外部环境做对接，因此给它定义为-- 接口 。而 虚基类 则更像一间毛胚房，整个架子已经有了（包括门口），想要什么东西就直接往里面放，但是摆放的东西跟整个架子的设计有关，不是所有的东西都能乱摆，就好像原本规划为洗手间的空间，总不能把床摆在里面吧（当然，你乐意也是可以的。）。 症解答 说到这里，其实已经能够感觉到它们的区别是什么了，表面上 虚基类 感觉更加强大一点，可以像 接口 那样声明一系列的方法（这里的方法是没有实现体的，在 虚基类 中我们把这类方法叫“虚方法”），又能定义一些共有的属性；但是，因为 虚基类 也是一个类型，是必须要继承与它才能够拥有这样的一些特性

注： derby只能允许一个会话连接，测试还行,生产环境都是mysql 来源： https://www.cnblogs.com/xiangyuguan/p/11099498.html

工作中用过这两个数据库，但都不是太深入，仅限于用而已，但给我留下的印象就是Pgsql更好些，因为这两个库我都遇到过数据丢失的问题，前者我通过网上方法加自己的判断有惊无险的恢复了，而后者搜索各种资料加问身边的专家都没办法。 刚网上搜了一下两者的区别，总体的感觉也是前者是最好的开源关系数据库，而后者是互联网行业应用最广泛的数据库， 可能应用等多发现的坑也多，网上相关资料也多。如果让我个人选没特殊要求情况下会选前者。 关于两个的区别可以看知乎上相关问题，回答很精彩， 其中一个如下。 一、 PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 MySQL 用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。 二、任何系统都有它的性能极限，在高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而 MySQL 明显出现一个波峰后下滑（5.5版本之后，在企业级版本中有个插件可以改善很多，不过需要付费）。 三、PG 多年来在 GIS 领域处于优势地位，因为它有丰富的几何类型，实际上不止几何类型，PG有大量字典、数组、bitmap 等数据类型，相比之下mysql就差很多