猫头鹰的深夜翻译：集成方式是如何影响微服务架构的
前言
当万维网首次出现时，集成不同类型的操作系统是一项主要的挑战。HTTP的出现使得不同的操作系统之间可以通过超文本使用统一的协议进行通信。
当微服务的架构出现后，系统的集成带来的挑战没有太大的分别：多种实现技术在物理网络上彼此分离，需要相互通信。从最终用户的角度来看，微服务的集成在系统的无缝体验方面起着至关重要的作用。正确集成的系统还有助于实现分布式系统的优势：它们可以在service级实现扩容提高效率，并且能够在满足业务需求的同时降低架构成本。
另一方面，错误集成的系统可能会彻底破坏微服务架构的好处：它可能会导致数据丢失和继承问题。这些问题通常很难追踪，同时用户会受到不良的影响。
无缝集成有许多因素需要考虑。我们需要针对不同的场景选择最合适的集成方式。接下来，我们会介绍不同集成方式的优缺点。
猫头鹰的深夜翻译：WeakHashMap
本文简介
WeakHashMap类概览WeakHashMap类构造器总结WeakHashMap类构造方法WeakHasjMap类使用举例
1. WeakHashMap类概览
WeakHashMap是一个实现了Map接口，并且键为weak型的哈希表。WeakHashMap中的条目不再被正常使用时，会被自动删除。它的键值均支持null。这个类类似于HashMap类，也具有初始容量和负载因子这样的效率参数。和绝大多数的集合类一样，这个类不是同步的。需要使用Collections.synchronizedMap方法来进行同步控制。弱引用–如果一个对象只有一个弱引用，那么垃圾回收期可以随时收回该对象的内存。它不需要等到系统内存不足时才回收。通常，它的内存会在下一次垃圾收集器运行时释放。
猫头鹰的深夜翻译：微服务概述
前言
在过去几年中，出现了微服务架构的理念，它提倡将应用程序设计为可独立部署到额服务套件。虽然对于这种架构风格没有明确的定义，但是它在业务能力，自动部署，智能终端以及语言和数据的分散控制方面有共同的特征。
微服务是软件架构中的一个新名词。在过去几年中，可以看到很多项目都采用了这种风格的架构，以至于他已经成为了构建企业应用程序的默认样式。然而，并没有太多的信息可以描述微服务架构的风格以及如何实现这种风格。
简而言之，微服务架构是将单应用开发成为一套分别运行在独立的线程并通过轻量级的机制如HTTP进行访问的方法。这些服务围绕业务功能构建，并且可以独立的全自动部署。这些服务无需集中管理，可以用不同的编程语言编写，并使用不同的数据存储技术。
在开始介绍微服务风格之前，可以先将其和单机应用做一个对比：单机应用是指将一个应用作为一个单元进行开发。企业应用通常包含三个部分：客户端UI（包含在用户浏览器上的HTML页面和JS脚本），一个数据库（关系型数据库）和服务端应用。服务端应用会处理HTTP请求，执行业务逻辑，从数据库获取和更新数据，并选择和生成HTML页面返回给浏览器。系统的任何变更都需要重新构建和部署新版本的服务端应用。
单机应用是构建系统的一种通用方法。处理请求的所有业务逻辑都运行在单线程中，你可以根据开发语言将应用份极为类，方法和命名域。你可以在笔记本上运行和测试应用，并使用部署流水线来确保变更已经进行过测试并部署到生产环境。你可以通过在负载均衡器后面运行许多实例来水平扩展单机应用。
单机应用在初期相当成功，但渐渐的人们会感到挫败–尤其当应用被部署到云商之后。变更周期被绑定在一起：应用的一个小变更需要整个应用重新构建和部署。随着时间的推移，通常很难保持一个良好的模块化结构，使得更难以将对模块的变更维持在单个模块内。扩展需要扩展整个应用程序，而不是应用中需要更多资源的部分。
这种挫败感引向了微服务架构风格：将应用构架为一组服务。每个服务不仅能够独立的部署和扩展，还能够提供一个稳定的模块边界，并且每个服务用不同的语言开发。他们还能交由不同的团队开发。
我们并没有表示微服务风格是创新的发明，它可以追溯回Unix的设计理念。但是我们认为有人还没能认真的考虑微服务架构，如果使用这种架构，软件开发将会更方便。
猫头鹰的深夜翻译：分布式系统Toolkit模式
过去几年容器逐渐成为了打包和部署代码的流行的方式。容器镜像解决很多现有的打包和部署工具所带来的问题，初次以外，还为我们提供了构建分布式应用的全新的思路。就如SOA提倡将应用拆分为模块化的内聚的服务，容器应当进一步提倡将这些服务拆分为紧密协作的模块化容器。通过构建应用边界，容器使用户能够使用模块化，可重用的组件构建其服务，从而使得服务比单机容器构建的应用程序更可靠，更具可扩展性并且构建速度更快。
从VM向容器的演变从各种角度来说就如同当年从单机应用转化为模块化的面向对象的应用程序。容器镜像提供的抽象层与面向对象编程中类的抽象边界有很大的共同点，而且也提高了开发者的效率和程序的质量。就像正确的编码方式是将关注点分离为模块化对象一样，在容器中打包应用程序的正确方法是将关注点分离为模块化容器。根本上来说，这意味着不仅要将整个应用程序分解，而且要将任何一个服务器中的各个部分分解为多个模块化容器，这些容器易于参数化和重复使用。这就像现代语言中的标准语言库，大多数应用程序开发人员可以将由其他人编写的模块化容器组合在一起，并使用更高质量的组件更快地构建应用程序。
从模块化容器方面进行思考的好处很多，特别是模块化容器提供以下内容：
猫头鹰的深夜翻译：对于RestAPI简单的基于身份的权限控制
前言
基于角色的权限控制（RBAC)是管理用户对某种资源或操作的权限的通用方法。权限可以明确指定可以访问的资源和操作。基本原理如下：权限将被分配给某个角色，并将该角色分配给某个用户或者是用户组，而不是直接分配给某个用户。
角色与权限捆绑##
将权限与单个用户关联起来是一件很复杂的事情，随着更多的用户使用系统，维护用户的权限变得更加困难，且容易出错。权限的错误分配会阻止用户访问所需的系统，甚至是允许非授权用户访问限制区域或是执行危险操作。
在这篇文章中，我会介绍如何对应用开启权限控制。权限控制的模型有许多种，比如RBAC（基于角色的权限控制），DAC（自由访问控制）等。虽然文档中解释的原则可以应用于各种模型，但我选择RBAC作为参考，因为它被广泛接受并且非常直观。
查看用户的活动通常只会产生用户执行的有限数量的操作（如读取数据，提交表单）。深入观察这些用户的行为会发现，这些行为通常一起执行，即执行A操作的用户往往也会执行B操作。比如，读取并更新报告，或者是添加和删除用户。这些都可以与角色绑定，比如编辑或是账户管理员。注意这里的角色并不一定和职称或是组织结构绑定，而是以有意义的方式反映相关的用户操作。当恰当划分好角色并分配给用户时，就可以将权限分配给每个角色，而非用户。管理少量角色的权限是一件相对简单的事情。
leetcode66.将数组表示的非负整数加一
题目要求：一个非负整数被表示为一个数组，数组中每一个元素代表该整数的一个位。数组的下标越小，代表的位数越高。现在对该数组做加一运算，请返回结果数组。
leetcode26.Remove Duplicate
题目要求：输入一个数组和一个值，删除数组中等于该值得元素。不允许分配新的内存空间（即不允许创建新的数组），允许数组中的元素的顺序发生变化，只要该数组在返回长度前的值正确
例如：输入nums = [3,2,2,3], val = 3，程序返回2，且nums数组的前两个值均为2