Martin

问题： 我已经阅读了有关测试中 的模拟 与存根的各种文章，包括 Martin Fowler的Mocks Are n't Stubs ，但仍然不了解它们之间的区别。 解决方案： 参考一： https://stackoom.com/question/EVux/模拟和存根有什么区别 参考二： https://oldbug.net/q/EVux/What-s-the-difference-between-a-mock-stub 来源： oschina 链接： https://my.oschina.net/stackoom/blog/4320451

https://blog.kuangstudy.com/index.php/archives/437/ 来源： oschina 链接： https://my.oschina.net/u/4382640/blog/4482288

综述 近两年来，Serverless 概念在开发者中交流的越来越多，实践、服务、产品层出不穷。 Serverless 的主题分享呈现爆发趋势，如在云原生领域颇具影响力的 KubeCon&CloudNativeCon 会议中，关于 Serverless 的主题，2018 年有 20 个，到 2019 年增长至 35 个。 产品层面，从最早的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等，面向计算的 Serverless 云上基础设施越来越丰富。 新概念、新产品的产生不是凭空出现，它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻，会逐步迭代问题的处理方法，提供更接近问题本质的解决方案。 若不从问题域出发来理解解决方案，容易陷入两个极端，即「它能解决一切问题」「它太超前了，理解不了」。 本篇文章尝试以日常开发流程为起点，分析每个阶段面对的问题，然后组合解决方案，提炼面向 Serverless 的开发模型，并与业界提出的 Serverless 产品形态做对应，为开发者采用 Serverless 架构和服务提供参考。 迭代模型 从项目整体视角来看： 这个模型的目标是满足客户需求。通过

背景 名词解释 如果你的团队目前正是构建微服务架构风格的软件系统，问自己两个问题？ 软件架构演进 软件架构大致经历了从单机架构，集中式架构，分布式微服架构，程序的层次图如下所示。 单机架构 特点如下： 1， 面向过程的设计方法； 2， 结构为CS； 3，程序的层次分两层，即UI层和数据库层； 4， 设计的核心在数据库和字段。 集中式架构 特点如下： 1， 面向对象的设计方法； 2，程序层次为经典的3层架构，即业务接入层， 业务逻辑层，数据库层； 3，部分企业也采用SOA架构风格； 4，集中式的架构缺点：扩展性，伸缩性差，系统容易变得臃肿； 分布式微服务架构 特点： 1， 基于微服务的理念：分而治之，模块高内聚（独立团队，独立部署，独立存储，技术异构），模块之间通过RPC或者HTTP通信，松耦合； 2，模块之间松耦合，解决了扩展性和伸缩性的问题； 架构对比 单体架构和集中式架构，系统分析， 系统设计，系统开发这3个阶段是割裂的，即分属3个不同的人或者小组或者岗位的人负责，这样的后果是： 1， 系统分析，设计，开发三个阶段的信息不一致，导致上线之后功能跟需求偏差非常大； 2， 系统的开发无法快速响应需求和业务的变化，错失发展的良机。 微服务的困局 微服务解决的问题 微服务解决了单体架构和集中式架构的问题：扩展性，弹性伸缩，敏捷开发快速响应业务变化； 但是微服务并非毫无缺陷。

一、Hive中load语句的语法说明 Hive Load语句不会在加载数据的时候做任何转换工作，而是纯粹的把数据文件复制/移动到Hive表对应的地址。语法格式如下： LOAD DATA [LOCAL] INPATH 'filepath' [OVERWRITE] INTO TABLE tablename \ [PARTITION (partcol1=val1, partcol2=val2 ...)] LOAD DATA [LOCAL] INPATH 'filepath' [OVERWRITE] INTO TABLE tablename \ [PARTITION (partcol1=val1, partcol2=val2 ...)] \ [INPUTFORMAT 'inputformat' SERDE 'serde'] (3.0 or later) 几点说明： 如果命令中带有LOCAL，说明从本地文件系统加载数据，文件路径可以是相对路径，也可以是绝对路径。在这种情况下，首先将文件从本地复制到hdfs相应的位置，然后移动到hive表格中，这个时候原始数据文件是存在于Hive表之下的路径下。 如果不包含LOCAL关键字，则移动HDFS文件到目标表中。 filepath 可以是一个相对路径，也可以是一个绝对路径。可以是一个文件，也可以是一个文件夹目录。如果是一个目录

作者 | 张羽辰（同昭）阿里云交付专家 导读 ：如今，几乎所有的事情都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来控制油门，你从未想过这会是某个工程师的代码。 当我们谈论架构时，我们到底在谈论什么？ 面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 buzzword 有点关系，的确我们这个领域充满了很多难以理解的词汇，这些词汇从英语翻译到中文已经丧失了部分上下文，再随着上下文的改变使得意义彻底扭曲，比如：引擎、框架、架构、应用、系统……诚然大家都或多或少对这些词语达成共识，在工作中使用这些词汇进行沟通，某时就是指“我们都懂的那个东西”，但是在我深入的想聊聊架构或者说软件架构时，的确不得不问自己这个问题，我们到底是谈论什么？ 事实上，架构这个词根据上下文所确定的范围较为固定，建筑学上的架构指代房屋结构、整体设计、组合构成等，而这些 high-level 设计往往并不需要全面了解底层，就像使用 RestTemplate 进行 WebService 调用时，我们也不关心 socket 是在四层连接的一样， 因为细节被隐藏了 。 但是，建筑学上的架构与软件架构却又极大的不同之处，问题出现在“软件”这个词上，按照 software 的词解，ware 是指产品一样的东西，而 soft 则强调易变，这是与 hardware 所对应的

微服务 微服务的由来 微服务的使用场景 微服务相较于单体架构的优点 微服务的本质 微服务的应用 微服务开发框架 微服务的由来 微服务最早由 Martin Fowler与James Lewis于2014年 共同提出，微服务架构风格是一种使用 一套小服务来开发单个应用 的方式途径， 每个服务运行在自己的进程中 ，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 微服务的使用场景 在传统的IT行业软件大多都是各种独立系统，他们的缺点就 是扩展性差，可靠性不高，维护成本高 。所以目前大部分公司都使用微服务进行开发。 微服务相较于单体架构的优点 （1） 单体架构所有的模块全都耦合在一块，代码量大，维护困难。 微服务每个模块就相当于一个单独的项目， 代码量明显减少，遇到问题也相对来说比较好解决。 （2） 单体架构所有的模块都共用一个数据库，存储方式比较单一。 微服务每个模块都 可以使用不同的存储方式 （比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。 （3） 单体架构所有的模块开发所使用的技术一样。 （比如用的开发语言是Java，就得整篇是Java，但是微服务不同，他可以多个服务使用不同的语言） 微服务每个模块都可以使用

背景 名词解释 如果你的团队目前正是构建微服务架构风格的软件系统，问自己两个问题？ 软件架构演进 软件架构大致经历了从单机架构，集中式架构，分布式微服架构，程序的层次图如下所示。 单机架构 特点如下： 1， 面向过程的设计方法； 2， 结构为CS； 3，程序的层次分两层，即UI层和数据库层； 4， 设计的核心在数据库和字段。 集中式架构 特点如下： 1， 面向对象的设计方法； 2，程序层次为经典的3层架构，即业务接入层， 业务逻辑层，数据库层； 3，部分企业也采用SOA架构风格； 4，集中式的架构缺点：扩展性，伸缩性差，系统容易变得臃肿； 分布式微服务架构 特点： 1， 基于微服务的理念：分而治之，模块高内聚（独立团队，独立部署，独立存储，技术异构），模块之间通过RPC或者HTTP通信，松耦合； 2，模块之间松耦合，解决了扩展性和伸缩性的问题； 架构对比 单体架构和集中式架构，系统分析， 系统设计，系统开发这3个阶段是割裂的，即分属3个不同的人或者小组或者岗位的人负责，这样的后果是： 1， 系统分析，设计，开发三个阶段的信息不一致，导致上线之后功能跟需求偏差非常大； 2， 系统的开发无法快速响应需求和业务的变化，错失发展的良机。 微服务的困局 微服务解决的问题 微服务解决了单体架构和集中式架构的问题：扩展性，弹性伸缩，敏捷开发快速响应业务变化； 但是微服务并非毫无缺陷。

作者：miracle1919 http://www.importnew.com/10780.html McGovernTheory在StackOverflow提了这样一个问题： Java虚拟机最多支持多少个线程？跟虚拟机开发商有关么？跟操作系统呢？还有其他的因素吗？ Eddie的回答: 这取决于你使用的CPU，操作系统，其他进程正在做的事情，你使用的Java的版本，还有其他的因素。我曾经见过一台Windows服务器在宕机之前有超过6500个线程。当然，大多数线程什么事情也没有做。一旦一台机器上有差不多6500个线程（Java里面），机器就会开始出问题，并变得不稳定。 以我的经验来看，JVM容纳的线程与计算机本身性能是正相关的。 当然了，你要有足够的本机内存，并且给Java分配了足够的内存，让每个线程都可以拥有栈(虚拟机栈)，可以做任何想做的事情。任何一台拥有现代CPU（AMD或者是Intel最近的几代）和1-2G内存（取决于操作系统）的机器很容易就可以支持有上千个线程的Java虚拟机。 如果你需要一个更精确的答案，最好是自己做压测。 Charlie Martin的回答: 这里有很多的参数（可以设置）。对于特定的虚拟机，都会有自己的运行时参数。（最大线程数）一定程度上由操作系统决定的：底层的操作系统要给线程提供哪些支持？施加哪些限制？虚拟机使用的是原生的操作系统的线程还是red

来源：kujiale webfe.kujiale.com/spring-could-heart/ Spring Cloud 是一个基于 Spring Boot 实现的微服务框架，它包含了实现微服务架构所需的各种组件。 注：Spring Boot 简单理解就是简化 Spring 项目的搭建、配置、组合的框架。因为与构建微服务本身没有直接关系，所以本文不对 Spring Boot 进行展开。 另外本文有一些例子涉及到 Spring 和 Spring Boot，建议先了解一下 Spring 和 Spring Boot 再阅读本文。 本文的阅读对象主要是没有接触过服务架构，想对其有一个宏观的了解的同学。 本文将从 Spring Cloud 出发，分两小节讲述微服务框架的「五脏六腑」： 第一小节「服务架构」旨在说明的包括两点，一服务架构是什么及其必要性；二是服务架构的基本组成。为什么第一节写服务架构而不是微服务架构呢？原因主要是微服务架构本身与服务架构有着千丝万缕的关系，服务架构是微服务架构的根基。 第二小节「五脏六腑」则将结合 Spring Cloud 这个特例来介绍一个完整的微服务框架的组成。 「服务架构」 为了方便理解，我先讲一个小故事：（改编自一知乎答主） Martin（微服务提出者也叫 Martin）刚来到公司时是一个基层员工，它上面有经理、老板，那个时候所有人都听老板的指挥。