什么是算法

  In mathematics and computer science, an algorithm is an unambiguous specification of how to solve a class of problems. Algorithms can perform calculation, data processing and automated reasoning tasks.
 在数学和计算机科学中，算法是如何解决一类问题的明确规范。 算法可以执行计算，数据处理和自动推理任务。

--- 维基百科

通俗的来讲，人们在给定一个输入条件由一定的简单计算步骤过后总能产生正确的输出结果，我们就把这些计算步骤统称为算法。

算法复杂度

每一个算法完成计算所需要花费的时间叫做时间复杂度 (Time Complexity),完成计算所需要花费的空间叫做空间复杂度 (Space Complexity)。通常来说，时间和空间两个维度是矛盾的，一个算法无法同时兼顾快速运行和低空间消耗。

在现代计算机中，由于存储空间的大幅提升所导致算法的空间复杂度已经被忽略了，所以本篇文章仅针对时间复杂度进行探讨。

随着时代的发展，多核CPU已经取代了过去的单核CPU。硬件技术的飞速发展让服务器的多线程的处理能力大大提升，为了提高应用程序的吞吐量和多系统协同处理能力，我们往往会同时运行多个线程去处理多个任务，这就是我们所说的–线程并发。

实际上，并发其实是一种解耦合的策略，它帮助我们把做什么（目标）和什么时候做（时机）分开。 比如，在Java Web应用中我们并不需要手动去为每一个用户请求创建线程。因为，在tomcat等服务容器的支持下，我们的Web应用可以以**单实例多线程**的方式运行，服务容器帮助我们对用户的并发请求进行了处理。这样，Web应用程序员就不用在去关心那些恶心的并发问题了(笑)。

JDK1.5中对于多线程编程来说java引入了新的启动、调度和管理线程的API。Executor框架就是其中之一，其内部使用了一个新的概念Thread Pool(线程池)。

简单来说，Thread Pool(线程池)就是装着一堆线程的仓库。我们可以对一个线程进行操作，也可以直接对整个线程池进行操作。为了防止生成的线程过多导致系统错误或者分配线程过少而浪费服务器性能，我们需要根据任务的不同对线程池进行合理的配置：

1. 任务优先级
2. 任务执行时间
3. 任务消耗资源类型：CPU、IO、多重混合
4. 任务是否依赖其他服务，例如数据库服务等

线程，作为CPU调度的最基本单位以及任务的执行者，其存在的数量决定了程序的执行吞吐量。

作为虚拟机，JVM也对物理计算机的多线程技术进行了实现，即在一个JVM虚拟机内可以执行多个Java线程。而对于物理机而言，绝大多数操作系统针对JVM是把内核线程（kernel thread）与 JVM线程进行一一对应的。

上面这些理解起来可能会比较绕，简单来说：物理计算机中一个JVM进程拥有多个内核线程（kernel thread）,一个内核线程对应JVM中的Java线程(java.lang.Thread)。如下图：

所以，对于JVM而言其部署的服务器的可开启的最大线程数既是JVM可开启的最大线程数。

数据仓库：堆、栈 - 关于JVM的内存模型

在JVM的运行时内存数据区中包含了：Method Area(方法区)、Heap Area(堆区)、Stack Area(栈区)、PC Registers(程序计数器)和Native Method Stack(本地方法栈)。

装卸工 ： ClassLoader

作为勤劳的底层员工，ClassLoader是生产过程的重要保障，它会将需要的Class字节码文件装载到内存当中，为程序的执行做准备工作。

上一篇我们知道了，类加载器ClassLoader分为Bootstrap ClassLoader(启动类装载器)、ExtClassLoader(扩展类装载器)和AppClassLoader(应用类装载器)，除了启动类装载器之外，其余的类加载器都必须继承java.lang.ClassLoader类。那么，我们先从java.lang.ClassLoader类开始分析吧。

作为一个JAVA程序开发者,见过太多的技术太多的框架,却对原本JDK的内容知之甚少。为了弥补这个遗憾,我将重新审视分析JDK

JVM - java运行的基础

关于JVM

Java虚拟机（英语：Java Virtual Machine，缩写为JVM），作为java平台运行的基础，它承担了运行java字节码的工作，在维基百科上是这样定义的：

A Java virtual machine (JVM) is an abstract computing machine that enables a computer to run a Java program. There are three notions of the JVM: specification, implementation, and instance. The specification is a document that formally describes what is required of a JVM implementation. Having a single specification ensures all implementations are interoperable. A JVM implementation is a computer program that meets the requirements of the JVM specification. An instance of a JVM is an implementation running in a process that executes a computer program compiled into Java bytecode.

Java虚拟机（JVM）是使计算机运行Java程序的抽象计算机器。 JVM有三种概念：规范，实现和实例。 规范是一个正式描述JVM实现所需要的文档，有一个单一的规范确保所有的实现是可互操作的。 JVM实现是一个满足JVM规范要求的计算机程序。 JVM的一个实例是运行在执行编译为Java字节码的计算机程序的进程中的实现。

作为一个JAVA程序开发者,见过太多的技术太多的框架,却对原本JDK的内容知之甚少。为了弥补这个遗憾,我将重新审视分析JDK

JDK里都有啥？

以jdk1.8为例，下图为jdk1.8的整体技术架构图：

[外传] 关于 Ribbon 和 Feign

  在微服务消费的学习过程中，我并没有像别的博主使用Feign和Ribbon。因为这两个东西如果直接放到博文中可能会导致读者的混乱，搞不清楚这两者的关系，所以我单独写一篇来介绍这两者的关系。

一. 关于Ribbon

什么是 Ribbon

Spring Cloud Netflix Ribbon 是由 Netflix 开源的客户端负载均衡的组件。使用 java 语言实现。

说白了，ribbon像是nginx中的负载均衡组件一样，用来实现客户端的负载均衡。

今天在学习使用Ribbon和RestTemplate集成的时候遇到一个小坑:

使用@LoadBalanced注解后的RestTemplate运行报错：

java.lang.IllegalStateException: No instances available for Maxith
	at org.springframework.cloud.netflix.ribbon.RibbonLoadBalancerClient.execute(RibbonLoadBalancerClient.java:90) ~[spring-cloud-netflix-core-1.3.4.RELEASE.jar:1.3.4.RELEASE]
	at org.springframework.cloud.client.loadbalancer.RetryLoadBalancerInterceptor$1.doWithRetry(RetryLoadBalancerInterceptor.java:103) ~[spring-cloud-commons-1.2.3.RELEASE.jar:1.2.3.RELEASE]
	at org.springframework.cloud.client.loadbalancer.RetryLoadBalancerInterceptor$1.doWithRetry(RetryLoadBalancerInterceptor.java:91) ~[spring-cloud-commons-1.2.3.RELEASE.jar:1.2.3.RELEASE]
	at org.springframework.retry.support.RetryTemplate.doExecute(RetryTemplate.java:287) ~[spring-retry-1.2.1.RELEASE.jar:na]
	at org.springframework.retry.support.RetryTemplate.execute(RetryTemplate.java:164) ~[spring-retry-1.2.1.RELEASE.jar:na]
	at org.springframework.cloud.client.loadbalancer.RetryLoadBalancerInterceptor.intercept(RetryLoadBalancerInterceptor.java:91) ~[spring-cloud-commons-1.2.3.RELEASE.jar:1.2.3.RELEASE]
	at org.springframework.http.client.InterceptingClientHttpRequest$InterceptingRequestExecution.execute(InterceptingClientHttpRequest.java:86) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.cloud.netflix.metrics.MetricsClientHttpRequestInterceptor.intercept(MetricsClientHttpRequestInterceptor.java:64) ~[spring-cloud-netflix-core-1.3.4.RELEASE.jar:1.3.4.RELEASE]
	at org.springframework.http.client.InterceptingClientHttpRequest$InterceptingRequestExecution.execute(InterceptingClientHttpRequest.java:86) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.http.client.InterceptingClientHttpRequest.executeInternal(InterceptingClientHttpRequest.java:70) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:53) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:652) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:613) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:287) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
	at org.springframework.web.client.RestTemplate$$FastClassBySpringCGLIB$$aa4e9ed0.invoke(<generated>) ~[spring-web-4.3.10.RELEASE.jar:4.3.10.RELEASE]
...

如果将@LoadBalanced注解去掉，则返回正确的结果，由于初学spring cloud，所以不是很明白为什么会出现这个问题，于是在网上找了半天，终于在stackoverflow找到了答案。

The RestTemplate you autowired is already connected to Ribbon. So you do a lookup by hand and then RestTemplate is trying to lookup the hostname passed in to ribbon. You have two options: 1) Don’t use the netflix DiscoveryClient and pass the serviceId as a logical hostname to ribbon (http://TEST/myservice), 2) Don’t use the autowired RestTemplate, create a new one for your class. My choice would be #1.

---- spencergibb

虽然这为朋友说的是对的，但是不是很好理解，其实说起来原因非常简单：

去掉DiscoveryClient ! 因为之前我们需要DiscoveryClient来获取一个服务的实例并执行，但是加入了@LoadBalanced注解过后就不需要寻找实例了，Ribbon会主动帮我们寻找适合的实例并执行，所以我们只需要传递一个服务地址给Ribbon就行了。

@RequestMapping("/call/{serverName}")
public String callServer(@PathVariable("serverName") String serverName) throws InterruptedException {
    return restTemplate.getForObject("http://" +serverName+"/say",String.class);
}

问题链接：Ribbon with Spring Cloud and Eureka: java.lang.IllegalStateException: No instances available for Samarths-MacBook-Pro.local

STEP 6 : API Gateway 之 Netflix Zuul

什么是API Gateway

API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。

API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API Gateway，然后路由这些请求到对应的微服务。API Gateway将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在web协议与内部使用的非Web友好型协议间进行转换，如HTTP协议、WebSocket协议。

API Gateway可以提供给客户端一个定制化的API。它暴露一个粗粒度API给移动客户端。以产品最终页这个使用场景为例。API Gateway提供一个服务提供点（/productdetails?productid=xxx）使得移动客户端可以在一个请求中检索到产品最终页的全部数据。API Gateway通过调用多个服务来处理这一个请求并返回结果，涉及产品信息、推荐、评论等。

简单的来说，API Gateway功能有点儿像nginx，它是整个系统服务的总入口（即网关），它可以将请求分发到不同的微服务上。

• 相比nginx，API Gateway是一个简化的轻量级的网关，它简化了内部服务相互调用的复杂度。
• 相比nginx，API Gateway能动态修改服务的地址，以及服务的启用和关闭，而不需要复杂的配置文件。

[外传] 关于服务发现框架Consul 、Zookeeper 、Eureka

作为分布式应用的基础，服务注册与发现是至关重要的，而Consul 、Zookeeper 、Eureka作为时下最火的三个框架自然也是需要拿出来比一比的。

三者的特点如下：

[外传] Spring Cloud Eureka Server服务注册中心高可用方案

在微服务架构中，作为核心的服务注册中心是整个系统的关键，它的高可用性决定了系统的整体的稳定性。

在前面的学习中我们讲到，Eureka Servers是单点运行的，但是它本身也算是一个微服务，所以它可以再多个Eureka Server实例中互相注册，这样就可以构建一个高可用的Eureka Server的服务集群。

STEP 5 : 分布式配置中心 - 进阶与整合

上一节我们学习了分布式配置中心config server，由于篇幅有限，所以上一节内容比较基础，在实际生产过程中还需要很多功能的集成。这一节我们将学习分布式配置中心的进阶使用和其他功能的整合。

一. 安全整合

1. 使用spring security进行密码鉴权

在配置中心服务中添加配置：

pom.xml引入spring security支持：

  
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

在application.properties中添加用户名和密码：

  
security.user.name=userName		//用户名默认是user
security.user.password=password		//默认使用随机密码写入到log中

STEP 4 : 分布式配置中心 (Spring Cloud Config)

什么是Spring Cloud Config

一个完整的项目通常会需要许多的配置文件，一般我们会将这些配置文件以多种方式存储，最常见的就是直接将properties或者yml文件直接打包到项目中，这样做虽然简单但是如果我们修改配置文件，就必须重新打包发布项目。如果这个项目正好是一个分布式服务，且需要发布到很多台服务器上，这样每次修改配置文件就会造成很大的工作量，这当然是我们不愿意看见的。

随着分布式微服务的不断增加，系统的可伸缩、可拓展性的重点就落到了配置管理这个问题上，所以就产生了配置中心这个概念，即所有的配置交由配置中心进行统一管理。

Spring Cloud Config即是一个分布式的配置中心，它具有中心化、版本控制、支持动态更新、平台独立、语言独立等特性。其特点是：

• 提供服务端和客户端支持(spring cloud config server和spring cloud config client)
• 集中式管理分布式环境下的应用配置
• 基于Spring环境，无缝与Spring应用集成
• 可用于任何语言开发的程序
• 默认实现基于git仓库，可以进行版本管理
• 可替换自定义实现

Spring Cloud Config官网是：https://cloud.spring.io/spring-cloud-config/