如果能跟踪每个请求，中间请求经过哪些微服务，请求耗时，网络延迟，业务逻辑耗时等。我们就能更好地分析系统瓶颈、解决系统问题。因此链路跟踪很重要。

链路追踪目的：解决错综复杂的服务调用中链路的查看。排查慢服务。

市面上链路追踪产品，大部分基于google的Dapper论文。

链路追踪要考虑的几个问题

1. 探针的性能消耗。尽量不影响 服务本尊。
2. 易用。开发可以很快接入，别浪费太多精力。
3. 数据分析。要实时分析。维度足够。

Sleuth

Sleuth是Spring cloud的分布式跟踪解决方案。

1. span(跨度)，基本工作单元。一次链路调用，创建一个span，span用一个64位id唯一标识。包括：id，描述，时间戳事件，spanId,span父id。

   span被启动和停止时，记录了时间信息，初始化span叫：root span，它的span id和trace id相等。

2. trace(跟踪)，一组共享“root span”的span组成的树状结构 称为 trace，trace也有一个64位ID，trace中所有span共享一个trace id。类似于一颗 span 树。

3. annotation（标签），annotation用来记录事件的存在，其中，核心annotation用来定义请求的开始和结束。

   • CS(Client Send客户端发起请求)。客户端发起请求描述了span开始。
   • SR(Server Received服务端接到请求)。服务端获得请求并准备处理它。SR-CS=网络延迟。
   • SS（Server Send服务器端处理完成，并将结果发送给客户端）。表示服务器完成请求处理，响应客户端时。SS-SR=服务器处理请求的时间。
   • CR（Client Received 客户端接受服务端信息）。span结束的标识。客户端接收到服务器的响应。CR-CS=客户端发出请求到服务器响应的总时间。

其实数据结构是一颗树，从root span 开始。

使用

在每个需要被监控的系统的pom中引入：

1
2
3
4
5

<!-- 引入sleuth依赖 -->
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-sleuth</artifactId>
		</dependency>

启动后，日志中可以看到类似于：[account-service,,,]的数据，说明如下：

1

[服务名称，traceId（一条请求调用链中 唯一ID），spanID（基本的工作单元，获取数据等），是否让zipkin收集和展示此信息]

zipkin

zipkin是twitter开源的分布式跟踪系统。

原理收集系统的时序数据，从而追踪微服务架构中系统延时等问题。还有一个友好的界面。

由4个部分组成：Collector（采集器）、Storage（存储器）、Restful API（接口）、Web UI

原理

sleuth收集跟踪信息通过http请求发送给zipkin server，zipkin将跟踪信息存储，以及提供RESTful API接口，zipkin ui通过调用api进行数据展示。

默认内存存储，可以用mysql，ES等存储。

使用

在每个需要被监控的系统的pom中引入：

1
2
3
4
5

<!-- zipkin -->
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-zipkin</artifactId>
		</dependency>

在每个需要监听的服务的配置文件中加入：

1
2
3
4
5
6
7
8

spring:
  #zipkin
  zipkin:
    base-url: http://localhost:9411/
    #采样比例1
  sleuth:
    sampler:
      rate: 1

根据zipkin官网中的Quickstart，启动zipkin。

监控告警

使用 Spring Boot2.x Actuator 监控应用

在项目的 POM 中引入

1
2
3
4

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

Endpoints

可以通过/actuator查看所有的暴露端点。

暴露配置

1
2
3
4
5
6
7
8
9

management:
  endpoints:
    web:
      exposure:
        include: '*' # 通过HTTP暴露所有的端点
      base-path: '/actuator'
    jmx:
      exposure:
        include: '*' # 通过JMX暴露所有的端点

health端点

health端点会聚合你程序的健康指标，来检查程序的健康情况。端点公开的应用健康信息取决于：management.endpoint.health.show-details=always

show-details的值：

• never 不展示详细信息，up或者down的状态，默认配置
• when-authorized 详细信息将会展示给通过认证的用户。授权的角色可以通过 management.endpoint.health.roles配置
• always 对所有用户暴露详细信息

metrics端点

metrics端点用来返回当前应用的各类重要度量指标，比如：内存信息、线程信息、垃圾回收信息、tomcat、数据库连接池等。

调用："http://localhost:8080/actuator/metrics/{requiredMetricName}" 获得各个指标。如：http://localhost:8080/actuator/metrics/jvm.memory.max

loggers端点

loggers 端点暴露了我们程序内部配置的所有logger的信息。

调用：http://localhost:8080/actuator/loggers获得所有的logger信息。

可以调用对应的POST接口，修改日志级别等。

info端点

info端点可以用来展示你程序的信息。我理解过来就是一些程序的基础信息。并且你可以按照自己的需求在配置文件 application.properties中个性化配置。

beans端点

beans端点会返回Spring 容器中所有bean的别名、类型、是否单例、依赖等信息。

heapdump端点

访问：http://localhost:8080/actuator/heapdump会自动生成一个 Jvm 的堆文件 heapdump。我们可以使用 JDK 自带的 Jvm监控工具，VisualVM 打开此文件查看内存快照。

threaddump 端点

主要展示了线程名、线程ID、线程的状态、是否等待锁资源、线程堆栈等信息。就是可能查看起来不太直观。访问：http://localhost:8080/actuator/threaddump

shutdown端点

这个端点属于操作控制类端点，可以优雅关闭 Spring Boot 应用。要使用这个功能首先需要在配置文件中开启：

1
2
3
4

management:
  endpoint:
    shutdown:
      enabled: true

由于 shutdown 接口默认只支持 POST 请求。

env端点

获取应用所有可用的环境属性报告

mappings端点

获取应用所有Spring Web的控制器映射关系报告

configprops端点

获取应用中配置的属性信息报告

SpringCloud Admin健康检查

Admin客户端

在要被监控的客户端添加pom引用：

1
2
3
4
5
6
7
8
9

<dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-starter-client</artifactId>
            <version>2.2.1</version>
        </dependency>
 <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

在配置文件中如下配置：

1
2
3
4
5

spring:
  boot:
    admin:
      client:
        url: http://localhost:9030

Admin服务端

新建一个项目，引入：

1
2
3
4
5

<dependency>
           <groupId>de.codecentric</groupId>
           <artifactId>spring-boot-admin-starter-server</artifactId>
           <version>2.2.1</version>
       </dependency>

然后添加注解@EnableAdminServer

• 从0开始用SpringCloud搭建微服务系统【一】
• 从0开始用SpringCloud搭建微服务系统【二】
• 从0开始用SpringCloud搭建微服务系统【三】
• 从0开始用SpringCloud搭建微服务系统【四】
• 从0开始用SpringCloud搭建微服务系统【五】

基本的容错模式有：

• 主动超时：
• 限流：限制最大并发数
• 熔断：错误数达到阈值时，类似保险丝熔断
• 隔离：隔离不同的依赖调用或者隔离不同的线程
• 降级：服务降低

容错理念：

• 凡是依赖都可能会失败
• 凡是资源都有限制
  • CPU/Memory/Threads/Queue
• 网络并不可靠
• 延迟是应用稳定性杀手

Netflix Hystrix

Hystrix实现了 超时机制和断路器模式。

Hystrix是Netflix开源的一个类库，用于隔离远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。主要有以下几点功能：

• 为系统提供保护机制。在依赖的服务出现高延迟或失败时，为系统提供保护和控制。
• 防止雪崩。
• 包裹请求：使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中运行。
• 跳闸机制：当某服务失败率达到一定的阈值时，Hystrix可以自动跳闸，停止请求该服务一段时间。
• 资源隔离：Hystrix为每个请求都的依赖都维护了一个小型线程池，如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。防止级联失败。
• 快速失败：Fail Fast。同时能快速恢复。侧重点是：（不去真正的请求服务，发生异常再返回），而是直接失败。
• 监控：Hystrix可以实时监控运行指标和配置的变化，提供近实时的监控、报警、运维控制。
• 回退机制：fallback，当请求失败、超时、被拒绝，或当断路器被打开时，执行回退逻辑。回退逻辑我们自定义，提供优雅的服务降级。
• 自我修复：断路器打开一段时间后，会自动进入“半开”状态，可以进行打开，关闭，半开状态的转换。

Hystrix设计原理

Hystrix的工作原理可以可以参考官网的How it Works。如果要看中文版，可以参考：Hystrix工作原理。

信号量隔离与线程隔离

默认情况下hystrix使用线程池控制请求隔离

线程池隔离技术，是用 Hystrix 自己的线程去执行调用；而信号量隔离技术，是直接让 tomcat 线程去调用依赖服务。信号量隔离，只是一道关卡，信号量有多少，就允许多少个 tomcat 线程通过它，然后去执行。

信号量隔离主要维护的是Tomcat的线程，不需要内部线程池，更加轻量级。

使用Hystrix

独立使用

独立使用Hystrix可以参考How To Use。

如果想要中文，可以参考：Hystrix都停更了，我为什么还要学？

与Resttemplate整合

引入依赖spring-cloud-starter-netflix-hystrix。

在Service中：

1
2
3
4
5
6
7
8
9
10
11
12
13

@Service
public class GreetingService {
    @HystrixCommand(fallbackMethod = "defaultGreeting")
    public String getGreeting(String username) {
        return new RestTemplate()
          .getForObject("http://localhost:9090/greeting/{username}", 
          String.class, username);
    }
  
    private String defaultGreeting(String username) {
        return "Hello User!";
    }
}

在Application中：

1
2
3
4
5
6
7

@SpringBootApplication
@EnableCircuitBreaker
public class RestConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(RestConsumerApplication.class, args);
    }
}

@EnableCircuitBreaker注释将扫描类路径以查找任何兼容的Circuit Breaker实现。

与Feign整合

在集成Feign的基础上修改如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@FeignClient(name = "statistics-service", fallback = StatisticsServiceClientFallback.class)
public interface StatisticsServiceClient {
	@RequestMapping(method = RequestMethod.PUT, value = "/statistics/{accountName}")
	void updateStatistics(@PathVariable("accountName") String accountName, Account account);
}
@Component
@Slf4j
public class StatisticsServiceClientFallback implements StatisticsServiceClient {
    @Override
    public void updateStatistics(String accountName, Account account) {
        log.error("Error during update statistics for account: {}", accountName);
    }
}

然后在配置文件中打开：

1

feign.hystrix.enabled=true

使用fallbackFactory检查具体错误

在一些场景中，简单的触发在 FeignClient 加入 Fallback 属性即可，而另外有一些场景需要访问导致回退触发的原因，那么这个时候可以在 FeignClient 中加入 FallbackFactory 属性即可；

1. 定义一个类，实现FallbackFactory

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@Component
public class WebError implements FallbackFactory<ConsumerApi> {
	@Override
	public ConsumerApi create(Throwable cause) {
		return new ConsumerApi() {
			@Override
			public String getById(Integer id) {
        //针对不同异常返回响应
				if(cause instanceof InternalServerError) {
					System.out.println("InternalServerError");
					return "远程服务报错";
				}else if(cause instanceof RuntimeException) {
					return "请求时异常：" + cause;
				}else {
					return "都算不上";
				}
				return null;
			}
		};
	}
}

1. @Feign中的使用@FeignClient(name = "statistics-service", fallbackFactory = WebError.class)

主要配置项

Hystrix Dashboard

Hystrix有一个不错的可选功能是能够在仪表板上监视其状态。 为了启用它，我们将spring-cloud-starter-hystrix-dashboard和spring-boot-starter-actuator放入项目的pom.xml中。

然后添加@EnableHystrixDashboard注解。

启动应用程序后，将浏览器指向http://localhost:8080/hystrix，输入“ hystrix.stream”的指标URL并开始监视。

参考：

• A Guide to Spring Cloud Netflix – Hystrix

• 从0开始用SpringCloud搭建微服务系统【一】
• 从0开始用SpringCloud搭建微服务系统【二】
• 从0开始用SpringCloud搭建微服务系统【三】
• 从0开始用SpringCloud搭建微服务系统【四】
• 从0开始用SpringCloud搭建微服务系统【五】

微服务间可以使用 HTTP 协议，RESTful 规范进行通信。Spring Cloud 提供了 2 种 RESTful 调用方式：Ribbon 和 Feign 。

Ribbon

客户端软负载组件，支持Eureka对接，支持多种可插拔LB策略。依赖 spring-cloud-starter-netflix-eureka-client 中已经默认加载了 Ribbon 的依赖。

Ribbon作为Spring Cloud的负载均衡机制的实现：

1. Ribbon可以单独使用，作为一个独立的负载均衡组件。只是需要我们手动配置 服务地址列表。
2. Ribbon与Eureka配合使用时，Ribbon可自动从Eureka Server获取服务提供者地址列表（DiscoveryClient），并基于负载均衡算法，请求其中一个服务提供者实例。
3. Ribbon与OpenFeign和RestTemplate进行无缝对接，让二者具有负载均衡的能力。OpenFeign默认集成了ribbon。

Ribbon 的自定义配置以及一些高级使用可以参考官方文档：Client Side Load Balancer: Ribbon

Ribbon组成

官网首页：https://github.com/Netflix/ribbon

ribbon-core: 核心的通用性代码。api一些配置。

ribbon-eureka：基于eureka封装的模块，能快速集成eureka。

ribbon-examples：学习示例。

ribbon-httpclient：基于apache httpClient封装的rest客户端，集成了负载均衡模块，可以直接在项目中使用。

ribbon-loadbalancer：负载均衡模块。

ribbon-transport：基于netty实现多协议的支持。比如http，tcp，udp等。

调用方式

使用RestTemplate

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Configuration
public class LoadBalancerClientConfig {
    /**
     * 负载均衡的RestTemplate。
     */
    @LoadBalanced
    @Bean(name = "loadBalanced")
    RestTemplate loadBalanced() {
        return new RestTemplate();
    }
    /**
     * 常规的RestTemplate。
     */
    @Primary
    @Bean(name = "restTemplate")
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

以上代码中使用 @LoadBalanced 注解，这样就可以让 RestTemplate 在请求时拥有客户端负载均衡的能力。

1
2
3
4
5
6
7
8

@Autowired
@Qualifier("loadBalanced")
private RestTemplate loadBalanced;
public String getTime() {
   return loadBalanced.getForEntity("http://service-producer/get_time", String.class).getBody();
}

使用DiscoveryClient

1
2
3
4
5
6
7
8
9
10
11
12

@Autowired
private DiscoveryClient discoveryClient;
   
   
public List<String> getAllInstance(@RequestParam("service_id") String serviceId) {
   List<ServiceInstance> instances = discoveryClient.getInstances(serviceId);
   return instances.stream()
           .map(instance -> String.format("http://%s:%s", instance.getHost(), instance.getPort()))
           .collect(Collectors.toList());
}

负载均衡算法

Ribbon 提供了很多负载均衡的策略。详情可见：

切换负载均衡策略

注解方式

1
2
3
4
5
6
7

@Configuration
public class DefaultRibbonConfig {
    @Bean
    public IRule ribbonRule() {
        return new BestAvailableRule();
    }
}

如上，配置IRule的新值，直接可以切换负载均衡策略

配置文件方式

给所有的服务指定负载均衡策略：

1
2
3

ribbon:
    NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule

给特定的服务指定负载均衡策略：

1

<服务名>.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule

Ribbon拦截

在服务调用的时候，我们可能不仅仅是简单地进行调用，会涉及到一些接口的校验、权限的校验等。要实现这些，可以实现ClientHttpRequestInterceptor接口。

1
2
3
4
5
6
7
8
9
10
11
12

public class LoggingClientHttpRequestInterceptor implements ClientHttpRequestInterceptor {
    @Override
    public ClientHttpResponse intercept(HttpRequest httpRequest, byte[] bytes, ClientHttpRequestExecution clientHttpRequestExecution) throws IOException {
        System.out.println("拦截啦！！！");
        System.out.println(httpRequest.getURI());
        ClientHttpResponse response = clientHttpRequestExecution.execute(httpRequest, bytes);
        System.out.println(response.getHeaders());
        return response;
    }
}

添加到resttemplate中

1
2
3
4
5
6
7
8

@LoadBalanced
@Bean(name = "loadBalanced")
@Primary
RestTemplate loadBalanced() {
    RestTemplate restTemplate = new RestTemplate();
    restTemplate.getInterceptors().add(new LoggingClientHttpRequestInterceptor());
    return restTemplate;
}

超时

Ribbon的配置如下：

1
2
3
4

#连接超时时间(ms)
ribbon.ConnectTimeout=1000
#业务逻辑超时时间(ms)
ribbon.ReadTimeout=6000

重试

1
2
3
4
5
6

#同一台实例最大重试次数,不包括首次调用
ribbon.MaxAutoRetries=1
#重试负载均衡其他的实例最大重试次数,不包括首次调用
ribbon.MaxAutoRetriesNextServer=1
#是否所有操作都重试
ribbon.OkToRetryOnAllOperations=false

使用ribbon重试机制，请求失败后，每个6秒会重新尝试

Feign

Feign 是 Netflix 开发的声明式、模板化的 HTTP 客户端，Feign 的使用非常简单，创建一个接口，在接口上加入一些注解，这样就完成了代码开发。

Feign 是一个 Http 请求调用的轻量级框架，可以以 Java 接口注解的方式调用 Http 请求，而不用像 Java 中通过封装 HTTP 请求报文的方式直接调用。通过处理注解，将请求模板化，当实际调用的时候，传入参数，根据参数再应用到请求上，进而转化成真正的请求，这种请求相对而言比较直观。Feign 封装 了HTTP 调用流程，面向接口编程

Spring Cloud OpenFeign

Spring Cloud OpenFeign 通过自动配置并绑定到Spring Environment和其他Spring编程模型习惯用法，为Spring Boot应用程序提供OpenFeign集成。

官方文档：Spring Cloud OpenFeign

服务调用

使用 Feign 必须引入 spring-cloud-starter-openfeign。在启动类 Application 上 @EnableFeignClients 注解。

服务提供者

1
2
3
4
5
6
7
8
9
10
11
12
13

@RequestMapping
public interface HelloApi {
    @GetMapping(value = "/v0.1/greeting")
    String greeting();
}
@RestController
public class HelloController implements HelloApi {
    @Override
    public String greeting(){
        return "hello world";
    }
}

服务消费者：简单使用

简单使用Feign不需要代码耦合，但是需要硬编码接口的信息。如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@FeignClient(value = "producer-service")
public interface HelloClient{
    @GetMapping(value = "/v0.1/greeting")
    String greeting();
}
@Service
public class TestService {
    @Autowired
    HelloClient helloClient;
    
    public String test(){
        helloClient.greeting();
    }
}

@FeignClient也可以脱离Eureka使用，如：@FeignClient(name = "xxx",url="") 这个url就是接口的地址。

服务消费者：接口继承方式

此方法需要引入服务提供者提供的接口jar包。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@FeignClient(value = "producer-service")
public interface HelloService extends HelloApi {
}
@Service
public class TestService {
    @Autowired
    HelloService helloService;
    
    public String test(){
        helloService.greeting();
    }
}

以上代码中，@FeignClient(value = "producer-service") 指定了使用哪一个服务。

高级用法

自定义配置

feign的默认配置类是：org.springframework.cloud.openfeign.FeignClientsConfiguration。默认定义了feign使用的编码器，解码器等。

允许使用@FeignClient的configuration的属性自定义Feign配置。自定义的配置优先级高于上面的FeignClientsConfiguration。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

@Configuration
@Slf4j
@EnableConfigurationProperties(FeignSecurityProperties.class)
@ConditionalOnClass(value = {RequestInterceptor.class, Decoder.class, Encoder.class})
public class FeignAutoConfig {
    @Autowired
    private FeignSecurityProperties feignSecurityProperties;
    /**
     * 内部微服务请求，加上timestamp，并且按字典序进行签名，附上sig
     *
     * @return RequestInterceptor 请求拦截器
     */
    @Bean
    @ConditionalOnMissingBean(RequestInterceptor.class)
    public RequestInterceptor requestTokenBearerInterceptor() {
        String apiSecretKey = feignSecurityProperties.getApiSignature().getInternalApiKey();
        return requestTemplate -> ApiSigUtil.sig(apiSecretKey, requestTemplate);
    }
    @Bean
    public Decoder feignDecoder() {
        HttpMessageConverter jacksonConverter = new MappingJackson2HttpMessageConverter(customObjectMapper());
        ObjectFactory<HttpMessageConverters> objectFactory = () -> new HttpMessageConverters(jacksonConverter);
        return new ResponseEntityDecoder(new SpringDecoder(objectFactory));
    }
    @Bean
    public Encoder feignEncoder() {
        HttpMessageConverter jacksonConverter = new MappingJackson2HttpMessageConverter(customObjectMapper());
        ObjectFactory<HttpMessageConverters> objectFactory = () -> new HttpMessageConverters(jacksonConverter);
        return new SpringEncoder(objectFactory);
    }
    public ObjectMapper customObjectMapper() {
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.configure(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT, true);
        return objectMapper;
    }
    @Bean
    @ConditionalOnMissingBean(Retryer.class)
    public Retryer feignRetryer() {
        return Retryer.NEVER_RETRY;
    }
    @Bean
    @ConditionalOnMissingBean(Request.Options.class)
    Request.Options feignOptions() {
        return new Request.Options(30 * 1000, 30 * 1000);
    }
}

如上面所示，在配置类上加上@Configuration注解，且该类在@ComponentScan所扫描的包中，那么该类中的配置信息就会被所有的@FeignClient共享。如果想要对某些的@FeignClient添加指定的配置，则：不指定@Configuration注解（或者指定configuration，用注解忽略），而是手动使用：@FeignClient(name = "service-valuation",configuration = FeignAuthConfiguration.class)

拦截器

上面代码中：

1
2
3
4
5
6

@Bean
    @ConditionalOnMissingBean(RequestInterceptor.class)
    public RequestInterceptor requestTokenBearerInterceptor() {
        String apiSecretKey = feignSecurityProperties.getApiSignature().getInternalApiKey();
        return requestTemplate -> ApiSigUtil.sig(apiSecretKey, requestTemplate);
    }

RequestInterceptor是一个请求拦截器，我们可以继承它做很多事情，如：

1
2
3
4
5
6
7
8
9
10

import feign.RequestInterceptor;
import feign.RequestTemplate;
public class MyBasicAuthRequestInterceptor implements RequestInterceptor {
	@Override
	public void apply(RequestTemplate template) {
		template.header("Authorization", "Basic cm9vdDpyb290");
	}
}

如果是BasicAuth认证，可以重写BasicAuthRequestInterceptor。

然后，在配置文件中添加：

1
2
3
4
5
6

feign:
  client: 
    config:  
      service-valuation: 
        request-interceptors:
        - cn.webfuse.passenger.feign.interceptor.MyBasicAuthRequestInterceptor

配置文件扩展

指定服务名配置：

1
2
3
4
5
6
7

feign:
  client: 
    config:  
      service-valuation: 
        connect-timeout: 5000
        read-timeout: 5000
        logger-level: full

通用配置:

1
2
3
4
5
6
7

feign:
     client: 
       config:  
         default: 
           connect-timeout: 5000
           read-timeout: 5000
           logger-level: full

属性配置比Java代码优先级高。也可通过配置设置java代码优先级高：

1
2
3

feign:
	client: 
		default-to-properties: false

压缩

1
2
3
4
5
6
7

feign:
  compression:  # 开启请求与响应的GZIP压缩
    request:
      enabled: true
      min-request-size: 10000 # 单位是B
    response:
      enabled: true

超时

Feign默认支持Ribbon；Ribbon的重试机制和Feign的重试机制有冲突，所以源码中默认关闭Feign的重试机制,使用Ribbon的重试机制。

保留原始异常信息

当调用服务时，如果服务返回的状态码不是200，就会进入到Feign的ErrorDecoder中，因此如果我们要解析异常信息，就要重写ErrorDecoder

原理

1. 主程序入口添加@EnableFeignClients注解开启对Feign Client扫描加载处理。根据Feign Client的开发规范，定义接口并加@FeignClient注解。
2. 当程序启动时，会进行包扫描，扫描所有@FeignClient注解的类，并将这些信息注入Spring IoC容器中。当定义的Feign接口中的方法被调用时，通过JDK的代理方式，来生成具体的RequestTemplate。当生成代理时，Feign会为每个接口方法创建一个RequestTemplate对象，该对象封装了HTTP请求需要的全部信息，如请求参数名、请求方法等信息都在这个过程中确定。
3. 然后由RequestTemplate生成Request，然后把这个Request交给client处理，这里指的Client可以是JDK原生的URLConnection、Apache的Http Client，也可以是Okhttp。最后Client被封装到LoadBalanceClient类，这个类结合Ribbon负载均衡发起服务之间的调用。

参考资源

• Service Discovery: Eureka Clients
• Service Discovery: Eureka Server
• 深度剖析服务发现组件Netflix Eureka
• 深入理解Eureka之源码解析
• 深入理解Ribbon之源码解析
• 深入理解Feign之源码解析

• 从0开始用SpringCloud搭建微服务系统【一】
• 从0开始用SpringCloud搭建微服务系统【二】
• 从0开始用SpringCloud搭建微服务系统【三】
• 从0开始用SpringCloud搭建微服务系统【四】
• 从0开始用SpringCloud搭建微服务系统【五】

1. 背景：在传统应用中，组件之间的调用，通过有规范的约束的接口来实现，从而实现不同模块间良好的协作。但是被拆分成微服务后，每个微服务实例的网络地址都可能动态变化，数量也会变化，使得原来硬编码的地址失去了作用。需要一个中心化的组件来进行服务的登记和管理。

2. 概念：实现服务治理，即管理所有的服务信息和状态。

3. 注册中心好处：不用关心有多少提供方。

4. 注册中心有哪些: Eureka，Nacos，Consul，Zookeeper等。

5. 服务注册与发现包括两部分，一个是服务器端，另一个是客户端。

   1. 服务端（Server）是一个公共服务，为Client提供服务注册和发现的功能，维护注册到自身的Client的相关信息，同时提供接口给Client获取注册表中其他服务的信息，使得动态变化的Client能够进行服务间的相互调用。
   2. 客户端（Client） 将自己的服务信息通过一定的方式登记到 Server上，并在正常范围内维护自己信息一致性，方便其他服务发现自己，同时可以通过Server获取到自己依赖的其他服务信息，完成服务调用，还内置了负载均衡器，用来进行基本的负载均衡。

服务端和客户端功能

server注册中心功能

1. 服务注册表：记录各个微服务信息，例如服务名称，ip，端口等。注册表提供查询 API（查询可用的微服务实例）和管理 API（用于服务的注册和注销）。
2. 服务注册与发现：
   1. 注册：将微服务信息注册到注册中心。
   2. 发现：查询可用微服务列表及其网络地址。
3. 服务检查：定时检测已注册的服务，如发现某实例长时间无法访问，就从注册表中移除。

client功能

1. 注册：每个微服务启动时，将自己的网络地址等信息注册到注册中心，注册中心会存储（内存中）这些信息。
2. 获取服务注册表：服务消费者从注册中心，查询服务提供者的网络地址，并使用该地址调用服务提供者，为了避免每次都查注册表信息，所以 client 会定时去 serve r拉取注册表信息到缓存到 client 本地。
3. 心跳：各个微服务与注册中心通过某种机制（心跳）通信，若注册中心长时间和服务间没有通信，就会注销该实例。
4. 调用：实际的服务调用，通过注册表，解析服务名和具体地址的对应关系，找到具体服务的地址，进行实际调用。

Eureka

• Eureka 是 Netflix 开源的一个 Restful 服务，主要用于服务的注册发现。它由两个组件组成：Eureka 服务器 和Eureka 客户端。
• Eureka 服务器用作服务注册服务器。各个节点启动后，会在 Eureka Server 中进行注册，这样 Eureka Server 中的服务注册表中将会存储所有可用服务节点的信息。
• Eureka 客户端是一个 Java 客户端，用来简化与服务器的交互，作为轮询负载均衡器，发现相关的服务，并提供服务的故障切换。
• Eureka 在设计时就优先保证可用性。即在 CAP 理论中，Eureka 满足 AP。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。
• Eureka 的几个时间点：
  • 在应用启动后，将会向 Eureka Server 发送心跳,默认周期为 30 秒。
  • 如果 Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 将会从服务注册表中把这个服务节点移除(默认90秒)。
  • Eureka Client 对已经获取到的注册信息做了 30s 缓存。即服务通过 Eureka 客户端第一次查询到可用服务地址后会将结果缓存，下次再调用时就不会真正向 Eureka 发起 HTTP 请求了。
  • 负载均衡组件 Ribbon 也有 30s 缓存。Ribbon 会从上面提到的 Eureka Client 获取服务列表，然后将结果缓存 30s。
  • 最大可能出现2分钟的延迟：注册延迟30s + Eureka服务器响应延迟30s + Eureka客户端更新延迟30s + Ribbon服务列表更新延迟30s。

• Eureka 启动保护机制：

  • 如果在 15 分钟内超过 85% 的节点都没有正常的心跳，那 么Eureka 就认为客户端与注册中心出现了网络故障。

  • 自我保护机制的触发条件：

    条件：当每分钟心跳次数( renewsLastMin ) 小于 numberOfRenewsPerMinThreshold 时，并且开启自动保护模式开关( eureka.server.enable-self-preservation = true ) 时，触发自我保护机制，不再自动过期续约。

    其中：

    1. numberOfRenewsPerMinThreshold = expectedNumberOfRenewsPerMin * 续租百分比( eureka.server.renewalPercentThreshold, 默认0.85 )

    2. expectedNumberOfRenewsPerMin = 当前注册的应用实例数 x 2 。为什么乘以 2： 默认情况下，注册的应用实例每半分钟续租一次，那么一分钟心跳两次，因此 x 2 。

       解释：服务实例数10个，期望每分钟续约数10 2=20，期望阈值200.85=17，自我保护少于17时 触发。】

  • Eureka 启动保护机制会出现以下情况：

    • Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
    • Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)。
    • 当网络稳定时，当前实例新的注册信息会被同步到其它节点中。

架构原理图

Eureka Server

引入依赖 spring-cloud-starter-netflix-eureka-server， 在启动类 Application 上，添加 @EnableEurekaServer 注解。

如果是单机服务，可以在 application.yml 中使用以下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

eureka:
  environment: dev  # 设置环境，可选
  server:
    enable-self-preservation: false  # 中小规模下，自我保护模式坑比好处多，所以关闭它
    renewal-threshold-update-interval-ms: 120000  # 心跳阈值计算周期，如果开启自我保护模式，可以改一下这个配置
    eviction-interval-timer-in-ms: 5000 # 主动失效检测间隔,配置成5秒
    use-read-only-response-cache: false # 禁用readOnlyCacheMap
    wait-time-in-ms-when-sync-empty: 0  #在Eureka服务器获取不到集群里对等服务器上的实例时，需要等待的时间，单机模式设置为0
  client:
    healthcheck: true
    service-url:
      defaultZone: http://${webfuse-security.user.name}:${webfuse-security.user.password}@localhost:2000/eureka/
    registry-fetch-interval-seconds: 5  # 定时刷新本地缓存时间
    register-with-eureka: false #表示是否将自己注册到Eureka Server，默认为true。由于当前这个应用就是Eureka Server，故而设为false。
    fetch-registry: false #表示是否从Eureka Server获取注册信息，默认为true。因为这是一个单点的Eureka Server，不需要同步其他的Eureka Server节点的数据，故而设为false。
  instance:
    hostname: ${hostname:localhost}
    instance-id: ${spring.application.name}@${spring.cloud.client.ip-address}:${server.port}    # 自定义实例ID
    prefer-ip-address: true
    lease-expiration-duration-in-seconds: 10  #  没有心跳的淘汰时间，10秒
    lease-renewal-interval-in-seconds: 5  # 心跳间隔，5秒

启动服务，可在 http://localhost:2000 查看项目页面。

Eureka Client

EurekaClient 可以在客户端获取eureka服务器上的注册者信息。

引入依赖 spring-cloud-starter-netflix-eureka-client, 在启动类 Application 上，添加 @EnableDiscoveryClient 注解。

在 application.yml 中使用以下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

eureka:
  environment: dev
  client:
    healthcheck:
      enabled: true
    service-url:
      defaultZone: http://user:password@192.168.1.16:8010/eureka/
    registry-fetch-interval-seconds: 5  # 定时刷新本地缓存时间
  instance:
    hostname: ${hostname:localhost}
    instance-id: ${spring.application.name}@${spring.cloud.client.ip-address}:${server.port}    # 自定义实例ID
    prefer-ip-address: true
    lease-expiration-duration-in-seconds: 10  #  没有心跳的淘汰时间，10秒
    lease-renewal-interval-in-seconds: 5  # 心跳间隔，5秒

启动项目即可。可在 http://localhost:2000 中看到注册的状态。

Eureka 高可用

Eureka Server 之间是可以互相注册的。

举个例子，我们有 3 个 Eureka 注册中心，端口分别为 2001 、 2002 和 2003 。那么端口为 2001 的最基本的配置如下：

1
2
3
4

eureka:
  client:
    service-url:
      defaultZone: http://localhost:2002/eureka/,http://localhost:2003/eureka/

端口 2002 和 2003 服务可以根据以上规则配置。

多网卡选择

服务器有多个网卡，eh0，eh1，eh2，只有eh0可以让外部其他服务访问进来，而Eureka client将eh1和eh2注册到Eureka server上，这样其他服务就无法访问该微服务了。有两种方式：

• 指定IP注册

  1 2 3 4

  eureka: instance: prefer-ip-address: true ip-address: 实际能访问到的IP

• 使用spring.cloud.inetutils配置网卡选择

Eureka健康检查

由于server和client通过心跳保持 服务状态，而只有状态为UP的服务才能被访问。看eureka界面中的status。

比如心跳一直正常，服务一直UP，但是此服务DB连不上了，无法正常提供服务。

此时，我们需要将 微服务的健康状态也同步到server。只需要启动eureka的健康检查就行。这样微服务就会将自己的健康状态同步到eureka。配置如下即可。

在client端加入Actuator，并配置eureka.client.healthcheck.enabled=true，将自己真正的健康状态传播到server。

通过代码来改动服务的状态：

1
2
3
4
5
6
7
8
9
10
11
12

@Component
@Data
public class HealthStatusHandler implements HealthIndicator {
    private Boolean status = true;
    @Override
    public Health health() {
        if (status) {
            return new Health.Builder().up().build();
        }
        return new Health.Builder().down().build();
    }
}

应用场景：比如说短信业务，欠费了等情况，可以暂时下线服务。

Eureka遇到的坑

available-replicas为空的问题

如果使用了eureka.instance.prefer-ip-address: true，然后eureka.client.service-url.defaultZone配置的IP与实例IP不一致，会出现available-replicas为空的问题。

解决方法：在eureka.instance.ip-address中强制设置IP，然后在eureka.client.service-url.defaultZone配置对应的IP。

Eureka 最佳实践

本人所在的公司由于体量小，生产环境直接使用 Eureka 的默认配置进行高可用性运行，目前也没有出现太大的问题。

以下是一些实践参考文章（注意：文章中的版本号不是最新的，可能在配置上会有调整）：

• Spring Cloud中，Eureka常见问题总结
• Eureka Clustering documentation and best practices
• Documentation: changing Eureka renewal frequency WILL break the self-preservation feature of the server

• 从0开始用SpringCloud搭建微服务系统【一】
• 从0开始用SpringCloud搭建微服务系统【二】
• 从0开始用SpringCloud搭建微服务系统【三】
• 从0开始用SpringCloud搭建微服务系统【四】
• 从0开始用SpringCloud搭建微服务系统【五】

微服务

从单体到微服务

单体服务

• 概念：所有功能全部打包在一起，也就是全部的功能都在一个应用包中。应用大部分是一个 war 包或 jar 包。

• 优点：容易开发、测试、部署，适合项目初期试错。

• 缺点：

  随着项目越来越复杂，团队不断扩大。坏处就显现出来了。

  • 复杂性高：代码多，十万行，百万行级别。加一个小功能，会带来其他功能的隐患，因为它们在一起。
  • 技术债务：人员流动，不坏不修，因为不敢修。
  • 持续部署困难：由于是全量应用，改一个小功能，全部部署，会导致无关的功能暂停使用。编译部署上线耗时长，不敢随便部署，导致部署频率低，进而又导致两次部署之间 功能修改多，越不敢部署，恶性循环。
  • 可靠性差：某个小问题，比如小功能出现 OOM，会导致整个应用崩溃。
  • 扩展受限：只能整体扩展，无法按照需要进行扩展， 不能根据计算密集型（派单系统）和IO密集型（文件服务） 进行合适的区分。
  • 阻碍创新：单体应用是以一种技术解决所有问题，不容易引入新技术。但在高速的互联网发展过程中，适应的潮流是：用合适的语言做合适的事情。比如在单体应用中，一个项目用 spring MVC，想换成s pring boot，切换成本很高，因为有可能10万，百万行代码都要改。

微服务

• Martin Fowler 在 2014年提出 Microservices架构

• 微服务是一种架构风格，将单体应用划分为小型的服务单元。

• 微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式。

  • 每个服务运行在自己的进程中
  • 服务间采用轻量级的方式进行通信（通常是HTTP API）
  • 这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。

• 优点：

  • 独立部署。不依赖其他服务，耦合性低，不用管其他服务的部署对自己的影响。
  • 易于开发和维护。关注特定业务，所以业务清晰，代码量少，模块变的易开发、易理解、易维护。
  • 启动快。功能少，代码少，所以启动快，有需要停机维护的服务，不会长时间暂停服务。
  • 局部修改容易。只需要部署 相应的服务即可，适合敏捷开发。
  • 技术栈不受限。java，node.js，go 等
  • 按需伸缩.某个服务受限，可以按需增加内存，cpu 等。
  • 职责专一。专门团队负责专门业务，有利于团队分工。
  • 代码复用。不需要重复写。底层实现通过接口方式提供。
  • 便于团队协作：每个团队只需要提供 API 就行，定义好 API 后，可以并行开发。
• 缺点：
  • 分布式固有的复杂性。容错，网络延时，调用关系、分布式事务等，都会带来复杂。
  • 分布式事务的挑战。每个服务有自己的数据库，有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL，评论用Mongodb等。目前最理想解决方案是：柔性事务的最终一致性。
  • 接口调整成本高。改一个接口，调用方都要改。
  • 测试难度提升。一个接口改变，所有调用方都得测。自动化测试就变得重要了，API文档的管理也尤为重要。
  • 运维要求高。需要维护几十上百个服务，监控变的复杂，并且还要关注多个集群。
  • 重复工作。比如 java 的工具类可以在共享 common.ja r中，但在多语言下行不通，C++ 无法直接用 java的 jar 包。

微服务组件

基于微服务的特性，微服务的组件不局限于技术的实现。主要的组件有：

• 服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。
• 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。
• 服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
• 配置中心：将本地化的配置信息（Properties、XML、YAML等形式）注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移，也是无状态特性。
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下，让用户能够在统一的界面中使用系统。Spring Cloud 就是一个集成框架。
• 调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
• 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker 等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能监控等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效。

常见的架构图

Spring Cloud

Spring Cloud 是实现微服务架构的一系列框架的有机集合。是在 Spring Boot 基础上构建的，用于简化分布式系统构建的工具集。是拥有众多子项目的项目集合。利用 Spring Boot 的开发便利性，巧妙地简化了分布式系统基础设施（服务注册与发现、熔断机制、网关路由、配置中心、消息总线、负载均衡、链路追踪等）的开发。

Spring Cloud的基础组件

• Eureka：服务注册与发现，用于服务管理。

• Feign： web调用客户端，能够简化HTTP接口的调用。

• Ribbon：基于客户端的负载均衡。

• Hystrix：熔断降级，防止服务雪崩。

• Zuul：网关路由，提供路由转发、请求过滤、限流降级等功能。

• Config：配置中心，分布式配置管理。

• Sleuth：服务链路追踪

• Admin：健康管理

• 从0开始用SpringCloud搭建微服务系统【一】
• 从0开始用SpringCloud搭建微服务系统【二】
• 从0开始用SpringCloud搭建微服务系统【三】
• 从0开始用SpringCloud搭建微服务系统【四】
• 从0开始用SpringCloud搭建微服务系统【五】

关键字

关键字有25个。关键字不能用于自定义名字，只能在特定语法结构中使用。

1
2
3
4
5

break      default       func     interface   select
case       defer         go       map         struct
chan       else          goto     package     switch
const      fallthrough   if       range       type
continue   for           import   return      var

预定义名字

大约有30多个预定义的名字，比如int和true等，主要对应内建的常量、类型和函数。

1
2
3
4
5
6
7
8
9
10

内建常量: true false iota nil
内建类型: int int8 int16 int32 int64
          uint uint8 uint16 uint32 uint64 uintptr
          float32 float64 complex128 complex64
          bool byte rune string error
内建函数: make len cap new append copy close delete
          complex real imag
          panic recover

其中：

• byte 是 uint8 类型的别名，存储 raw data
• rune 是 int32 类型的别名，存储一个 Unicode code point 字符

这些内部预先定义的名字并不是关键字，你可以在定义中重新使用它们。在一些特殊的场景中重新定义它们也是有意义的，但是也要注意避免过度而引起语义混乱。

命名规则

Go语言中的函数名、变量名、常量名、类型名、语句标号和包名等所有的命名，都遵循一个简单的命名规则：一个名字必须以一个字母（Unicode字母）或下划线开头，后面可以跟任意数量的字母、数字或下划线。

如果一个名字是在函数内部定义，那么它的就只在函数内部有效。如果是在函数外部定义，那么将在当前包的所有文件中都可以访问。名字的开头字母的大小写决定了名字在包外的可见性。如果一个名字是大写字母开头的（必须是在函数外部定义的包级名字；包级函数名本身也是包级名字），那么它将是导出的，也就是说可以被外部的包访问。

命名的建议：

• 推荐使用 驼峰式 命名，当名字由几个单词组成时优先使用大小写分隔，而不是优先用下划线分隔。
• 包本身的名字一般总是用小写字母。
• 名字的长度没有逻辑限制，但是Go语言的风格是尽量使用短小的名字，对于局部变量尤其是这样。
• 如果一个名字的作用域比较大，生命周期也比较长，那么用长的名字将会更有意义。

声明和变量

• var 用于声明变量
• const 用于声明常量
• type 用于声明一个新的类型
• func 用于声明一个函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var foo int 			// 无初值的声明
var foo int = 42 		// 带初值的声明
var foo, bar int = 42, 1302	// 一次性声明并初始化多个变量
var foo = 42 			// 类型推断，由使用的上下文决定
foo := 42 			// 简短模式，自动推断类型，并且必须在函数体内部
const constant = "This is a constant" //声明一个常量
type MyInt struct{ //声明一个类型
    
}  
func fooFuc(){  //声明一个函数
    
}

• var 形式的声明语句往往是用于需要显式指定变量类型地方，或者因为变量稍后会被重新赋值而初始值无关紧要的地方。
• 简短模式有以下限制：
  • 定义变量，同时显式初始化。
  • 不能提供数据类型。
  • 只能用在函数内部。
  • 由于使用了:=，而不是赋值的=，因此推导声明写法的左值变量必须是没有定义过的变量。若定义过，将会发生编译错误。
  • 在多个短变量声明和赋值中，至少有一个新声明的变量出现在左值中，即便其他变量名可能是重复声明的，编译器也不会报错。
• 当一个变量被声明之后，系统自动赋予它该类型的零值：int 为 0，float 为 0.0，bool 为 false，string 为空字符串，指针为 nil 等。所有的内存在 Go 中都是经过初始化的。

匿名变量

匿名变量的特点是一个下画线“”，“”本身就是一个特殊的标识符，被称为空白标识符。它可以像其他标识符那样用于变量的声明或赋值（任何类型都可以赋值给它），但任何赋给这个标识符的值都将被抛弃，因此这些值不能在后续的代码中使用，也不可以使用这个标识符作为变量对其它变量进行赋值或运算。使用匿名变量时，只需要在变量声明的地方使用下画线替换即可。

1
2
3
4
5
6
7
8

func GetData() (int, int) {
    return 100, 200
}
func main(){
    a, _ := GetData()
    _, b := GetData()
    fmt.Println(a, b)
}

变量的生命周期

• 对于在包一级声明的变量来说，它们的生命周期和整个程序的运行周期是一致的。
• 局部变量的声明周期则是动态的：每次从创建一个新变量的声明语句开始，直到该变量不再被引用为止，然后变量的存储空间可能被回收。
• 函数的参数变量和返回值变量都是局部变量。它们在函数每次被调用的时候创建。

常量

常量表达式的值在编译期计算，而不是在运行期。

iota 常量生成器

常量声明可以使用iota常量生成器初始化，它用于生成一组以相似规则初始化的常量，但是不用每行都写一遍初始化表达式。在一个const声明语句中，在第一个声明的常量所在的行，iota将会被置为0，然后在每一个有常量声明的行加一。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

type Weekday int
const (
    Sunday Weekday = iota
    Monday
    Tuesday
    Wednesday
    Thursday
    Friday
    Saturday
)
const (
    _ = 1 << (10 * iota)
    KiB // 1024
    MiB // 1048576
    GiB // 1073741824
    TiB // 1099511627776             (exceeds 1 << 32)
    PiB // 1125899906842624
    EiB // 1152921504606846976
    ZiB // 1180591620717411303424    (exceeds 1 << 64)
    YiB // 1208925819614629174706176
)

new 和 make

new 和 make 是两个内置函数，主要用来创建并分配类型的内存。new 只分配内存，而 make 只能用于 slice、map 和 channel 的初始化。

• new 函数只接受一个参数，这个参数是一个类型，并且返回一个指向该类型内存地址的指针。同时 new 函数会把分配的内存置为零，也就是类型的零值。

1
2
3
4
5
6
7
8
9
10
11
12
13

var sum *int
sum = new(int) //分配空间
*sum = 98
fmt.Println(*sum)
type Student struct {
   name string
   age int
}
var s *Student
s = new(Student) //分配空间。如果我们不使用 new 函数为自定义类型分配空间，就会报错
s.name ="dequan"
fmt.Println(s)

• make 也是用于内存分配的，但是和 new 不同，它只用于 chan、map 以及 slice 的内存创建，而且它返回的类型就是这三个类型本身，而不是他们的指针类型，因为这三种类型就是引用类型，所以就没有必要返回他们的指针了。

运算符

包（ package ）

• main package 才是可执行文件
• package 名字与 import 路径的最后一个单词一致（如导入 math/rand 则 package 叫 rand）
• 写开头的标识符（变量名、函数名…），对其他 package 是可访问的
• 小写开头的标识符，对其他 package 是不可见的

包的初始化

• 包的初始化首先是解决包级变量的依赖顺序，然后按照包级变量声明出现的顺序依次初始化。
• 如果包中含有多个.go源文件，它们将按照发给编译器的顺序进行初始化，Go语言的构建工具首先会将.go文件根据文件名排序，然后依次调用编译器编译。
• 每个包在解决依赖的前提下，以导入声明的顺序初始化，每个包只会被初始化一次。
• 初始化工作是自下而上进行的，main包最后被初始化。以这种方式，可以确保在main函数执行之前，所有依赖的包都已经完成初始化工作了。

init初始化函数

对于在包级别声明的变量，如果有初始化表达式则用表达式初始化，还有一些没有初始化表达式的，例如某些表格数据初始化并不是一个简单的赋值过程。在这种情况下，我们可以用一个特殊的init初始化函数来简化初始化工作。每个文件都可以包含多个init初始化函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package popcount
// pc[i] is the population count of i.
var pc [256]byte
func init() {
    for i := range pc {
        pc[i] = pc[i/2] + byte(i&1)
    }
}
// PopCount returns the population count (number of set bits) of x.
func PopCount(x uint64) int {
    return int(pc[byte(x>>(0*8))] +
        pc[byte(x>>(1*8))] +
        pc[byte(x>>(2*8))] +
        pc[byte(x>>(3*8))] +
        pc[byte(x>>(4*8))] +
        pc[byte(x>>(5*8))] +
        pc[byte(x>>(6*8))] +
        pc[byte(x>>(7*8))])
}

数据类型

数据类型分为：基础类型、复合类型、引用类型和接口类型。

• 基础类型，包括：数字、字符串和布尔型等
• 复合数据类型：数组和结构体等
• 引用类型包括：指针、切片、字典、函数、通道等

基础类型

• uint 32 位或 64 位
• uint8 无符号 8 位整型 (0 到 255)
• uint16 无符号 16 位整型 (0 到 65535)
• uint32 无符号 32 位整型 (0 到 4294967295)
• uint64 无符号 64 位整型 (0 到 18446744073709551615)
• int 32 位或 64 位
• int8 有符号 8 位整型 (-128 到 127)
• int16 有符号 16 位整型 (-32768 到 32767)
• int32 有符号 32 位整型 (-2147483648 到 2147483647)
• int64 有符号 64 位整型 (-9223372036854775808 到 9223372036854775807)
• byte uint8 的别名(type byte = uint8)
• rune int32 的别名(type rune = int32)，表示一个 unicode 码
• uintptr “无符号整型，用于存放一个指针是一种无符号的整数类型，没有指定具体的 bit 大小但是足以容纳指针。uintptr 类型只有在底层编程是才需要，特别是Go 语言和 C 语言函数库或操作系统接口相交互的地方。”
• float32 IEEE-754 32 位浮点型数
• float64 IEEE-754 64 位浮点型数
• complex64 32 位实数和虚数
• complex128 64 位实数和虚数
• string 字符串，默认值是空字符串，而非 NULL

复合数据类型

复合数据类型类型包括数组、结构体、切片、字典等。

struct

Go 语言中没有 class 类的概念，取而代之的是 struct，struct 的方法对应到类的成员函数。

结构类型可以用来描述一组数据值，这组值的本质既可以是原始的，也可以是非原始的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

// struct 是一种类型，也是字段成员的集合体
// 声明 struct
type Vertex struct {
    X, Y int
}
// 结构体的定义只是一种内存布局的描述，只有当结构体实例化时，才会真正地分配内存，因此必须在定义结构体并实例化后才能使用结构体的字段。
// 初始化 struct
var v = Vertex{1, 2}			// 字段名有序对应值
var v = Vertex{X: 1, Y: 2} 		// 字段名对应值
var v = []Vertex{{1,2},{5,2},{5,5}}	// 初始化多个 struct 组成的 slice
//用键值对填充结构体的例子
type People struct {
    name  string
    child *People
}
relation := &People{
    name: "爷爷",
    child: &People{
        name: "爸爸",
        child: &People{
                name: "我",
        },
    },
}
// 创建指针类型的结构体。实例化以后，实例的类型为 *T，属于指针。
vertex := new(Vertex)
// 取结构体的地址实例化。对结构体进行&取地址操作时，视为对该类型进行一次 new 的实例化操作。
// 实例化以后，实例的类型为 *T，属于指针。
v := &Vertex{}
// 访问成员
v.X = 4
// 在 func 关键字和函数名之间，声明接收者是 struct
// 在方法内部，struct 实例被复制，传值引用
func (v Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}
// 调用方法(有接收者的函数)
v.Abs()
// 有的方法接收者是指向 struct 的指针
// 此时在方法内调用实例，将是传址引用
func (v *Vertex) add(n float64) {
    v.X += n
    v.Y += n
}
//取地址实例化是最广泛的一种结构体实例化方式，可以使用函数封装上面的初始化过程
type Command struct {
    Name    string    // 指令名称
    Var     *int      // 指令绑定的变量
    Comment string    // 指令的注释
}
func newCommand(name string, varref *int, comment string) *Command {
    return &Command{
        Name:    name,
        Var:     varref,
        Comment: comment,
    }
}
cmd = newCommand(
    "version",
    &version,
    "show version",
)

匿名结构体

使用 map[string]interface{} 开销更小且更为安全。

1
2
3

point := struct {
	X, Y int
}{1, 2}

array

1
2
3
4
5
6
7
8
9
10
11
12
13

var a [10]int // 声明长度为 10 的 int 型数组，注意数组类型 = （元素类型 int，元素个数 10）
a[3] = 42     // 设置元素值
i := a[3]     // 读取元素值
// 声明并初始化数组
var a = [2]int{1, 2}
a := [2]int{1, 2} 	// 简短声明
a := [...]int{1, 2}	// 数组长度使用 ... 代替，编译器会自动计算元素个数
//遍历数组
for k, v := range a {
    fmt.Println(k, v)
}

list

在Go语言中，列表使用 container/list 包来实现，内部的实现原理是双链表，列表能够高效地进行任意位置的元素插入和删除操作。

初始化：

• 变量名 := list.New()
• var 变量名 list.List

1
2
3
4
5
6
7
8
9
10
11

l := list.New()
l.PushBack("fist")  //在尾部插入
l.PushFront(67) //在头部插入
 
l.Remove(element) // 移除 element 变量对应的元素。
//遍历
for i := l.Front(); i != nil; i = i.Next() {
    fmt.Println(i.Value)
}

slice

切片是有三个字段的数据结构，指向底层数组的指针，切片访问元素的个数（长度），切片允许增长到的元素的个数（容量）,这种数据结构便于使用和管理数据集。切片围绕动态数组的概念构建的，可以按需自动增长和缩小。切片是一个很小的对象，对底层数组进行了抽象，并提供相关的操作方法，切片的底层内存是在连续块中分配的。

语法：

slice [开始位置 : 结束位置]

• slice：表示目标切片对象；
• 开始位置：对应目标切片对象的索引；
• 结束位置：对应目标切片的结束索引。

从数组或切片生成新的切片拥有如下特性：

• 取出的元素数量为：结束位置 - 开始位置；
• 取出元素不包含结束位置对应的索引，切片最后一个元素使用 slice[len(slice)] 获取；
• 当缺省开始位置时，表示从连续区域开头到结束位置；
• 当缺省结束位置时，表示从开始位置到整个连续区域末尾；
• 两者同时缺省时，与切片本身等效；
• 两者同时为 0 时，等效于空切片，一般用于切片复位。

根据索引位置取切片 slice 元素值时，取值范围是（0～len(slice)-1），超界会报运行时错误，生成切片时，结束位置可以填写 len(slice) 但不会报错。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

var a []int           		// 声明 slice，相当于声明未指定长度的数组
var a = []int {1, 2, 3, 4}	// 声明并初始化 slice (基于 {} 中给出的底层数组)
a := []int{1, 2, 3, 4}		// 简短声明
chars := []string{0:"a", 2:"c", 1: "b"}  // ["a", "b", "c"]
var b = a[lo:hi]	// 创建从 lo 到 hi-1 的 slice 
var b = a[1:4]		// 创建从 1  到 3    的 slice
var b = a[:3]		// 缺省 start index 则默认为 0 
var b = a[3:]		// 缺省 end   index 则默认为 len(a)
a =  append(a,17,3)	// 向 slice a 中追加 17 和 3
c := append(a,b...)	// 合并两个 slice
// 使用 make 创建 slice
a = make([]byte, 5, 5)	// 第一个参数是长度，第二个参数是容量
a = make([]byte, 5)	// 容量参数是可选的
// 从数组创建 slice
x := [3]string{"Лайка", "Белка", "Стрелка"}
s := x[:] 		// slice s 指向底层数组 x
// 内置函数 copy() 可以将一个数组切片复制到另一个数组切片中，如果加入的两个数组切片不一样大，就会按照其中较小的那个数组切片的元素个数进行复制。
slice1 := []int{1, 2, 3, 4, 5}
slice2 := []int{5, 4, 3}
copy(slice2, slice1) // 只会复制slice1的前3个元素到slice2中
copy(slice1, slice2) // 只会复制slice2的3个元素到slice1的前3个位置

map

map (映射)是一种数据结构，用于存储一系列无序的键值对。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

var m map[string]int
m = make(map[string]int)
m["key"] = 42
fmt.Println(m["key"])
delete(m, "key")
elem, ok := m["key"] // 检查 m 中是否键为 key 的元素，如果有 ok 才为 true
// 使用键值对的形式来初始化 map
var m = map[string]Vertex{
    "Bell Labs": {40.68433, -74.39967},
    "Google":    {37.42202, -122.08408},
}
// 从映射获取值并判断键是否存在
value, exits := colors["blue"]
if exits {
    // blue
    fmt.Println(value)
}
// 使用range迭代映射
for key, value := range colors {
    // key:red value:red
    fmt.Printf("key:%s value:%s\n", key, value)
}

Go语言中的 map 在并发情况下，只读是线程安全的，同时读写是线程不安全的。1.9 版本中提供了一种效率较高的并发安全的 sync.Map。

指针

一个指针变量可以指向任何一个值的内存地址，它所指向的值的内存地址在 32 和 64 位机器上分别占用 4 或 8 个字节，占用字节的大小与所指向的值的大小无关。

当一个指针被定义后没有分配到任何变量时，它的默认值为 nil。指针变量通常缩写为 ptr。

每个变量在运行时都拥有一个地址，这个地址代表变量在内存中的位置。Go语言中使用在变量名前面添加 &操作符（前缀）来获取变量的内存地址（取地址操作），格式如下：

ptr := &v // v 的类型为 T

==其中 v 代表被取地址的变量，变量 v 的地址使用变量 ptr 进行接收，ptr 的类型为*T，称做 T 的指针类型，*代表指针。==

变量、指针和地址三者的关系是，每个变量都拥有地址，指针的值就是地址。

从指针获取指针指向的值： 当使用&操作符对普通变量进行取地址操作并得到变量的指针后，可以对指针使用*操作符，也就是指针取值。

变量、指针地址、指针变量、取地址、取值的相互关系和特性如下：

• 对变量进行取地址操作使用&操作符，可以获得这个变量的指针变量。
• 指针变量的值是指针地址。
• 对指针变量进行取值操作使用*操作符，可以获得指针变量指向的原变量的值。

*操作符的根本意义就是操作指针指向的变量。当操作在右值时，就是取指向变量的值，当操作在左值时，就是将值设置给指向的变量。

new() 函数可以创建一个对应类型的指针，创建过程会分配内存，被创建的指针指向默认值。

通道

如果说goroutine是Go语言程序的并发体的话，那么channels则是它们之间的通信机制。一个channel是一个通信机制，它可以让一个goroutine通过它给另一个goroutine发送值信息。每个channel都有一个特殊的类型，也就是channels可发送数据的类型。

通道的声明如下：

1

ch := make(chan 类型)

如： ch := make(chan int) // ch has type 'chan int'

两个相同类型的channel可以使用==运算符比较。如果两个channel引用的是相同的对象，那么比较的结果为真。一个channel也可以和nil进行比较。

channel的发送和接受操作：

• 一个发送语句将一个值从一个goroutine通过channel发送到另一个执行接收操作的goroutine
• 发送和接收两个操作都使用<-运算符
• 在发送语句中，<-运算符分割channel和要发送的值
• 在接收语句中，<-运算符写在channel对象之前。一个不使用接收结果的接收操作也是合法的

示例如下：

1
2
3

ch <- x  // a send statement
x = <-ch // a receive expression in an assignment statement
<-ch     // a receive statement; result is discarded

不带缓存的channel

• 一个基于无缓存Channels的发送操作将导致发送者goroutine阻塞，直到另一个goroutine在相同的Channels上执行接收操作。
• 如果接收操作先发生，那么接收者goroutine也将阻塞，直到有另一个goroutine在相同的Channels上执行发送操作。
• 无缓存Channels有时候也被称为同步Channels。当通过一个无缓存Channels发送数据时，接收者收到数据发生在唤醒发送者goroutine之前。

串联的Channels（Pipeline）

Channels也可以用于将多个goroutine连接在一起，一个Channel的输出作为下一个Channel的输入。这种串联的Channels就是所谓的管道（pipeline）。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

func main() {
    naturals := make(chan int)
    squares := make(chan int)
    // Counter
    go func() {
        for x := 0; x < 100; x++ {
            naturals <- x
        }
        close(naturals)
    }()
    // Squarer
    go func() {
        for x := range naturals {
            squares <- x * x
        }
        close(squares)
    }()
    // Printer (in main goroutine)
    for x := range squares {
        fmt.Println(x)
    }
}

单方向的Channel

Go语言的类型系统提供了单方向的channel类型，分别用于只发送或只接收的channel。箭头<-和关键字chan的相对位置表明了channel的方向。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

func counter(out chan<- int) {
    for x := 0; x < 100; x++ {
        out <- x
    }
    close(out)
}
func squarer(out chan<- int, in <-chan int) {
    for v := range in {
        out <- v * v
    }
    close(out)
}
func printer(in <-chan int) {
    for v := range in {
        fmt.Println(v)
    }
}
func main() {
    naturals := make(chan int)
    squares := make(chan int)
    go counter(naturals)
    go squarer(squares, naturals)
    printer(squares)
}

带缓存的Channels

带缓存的Channel内部持有一个元素队列。队列的最大容量是在调用make函数创建channel时通过第二个参数指定的。

向缓存Channel的发送操作就是向内部缓存队列的尾部插入元素，接收操作则是从队列的头部删除元素。如果内部缓存队列是满的，那么发送操作将阻塞直到因另一个goroutine执行接收操作而释放了新的队列空间。相反，如果channel是空的，接收操作将阻塞直到有另一个goroutine执行发送操作而向队列插入元素。

数据类型转换

由于Go语言不存在隐式类型转换，因此所有的类型转换都必须显式的声明：

1
2
3

xvalueOfTypeB = typeB(valueOfTypeA)
类型 B 的值 = 类型 B(类型 A 的值)

只有相同底层类型的变量之间可以进行相互转换（如将 int16 类型转换成 int32 类型），不同底层类型的变量相互转换时会引发编译错误（如将 bool 类型转换为 int 类型）。

函数

函数的基本语法为：

1
2
3

func 函数名(形式参数列表)(返回值列表){
    函数体
}

基本函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// 最简单的函数
func functionName() {}
// 带参数的函数(注意类型也是放在标识符之后的)
func functionName(param1 string, param2 int) {}
// 类型相同的多个参数
func functionName(param1, param2 int) {}
// 声明返回值的类型
func functionName() int {
    return 42
}
// 定义多个变量接受，多返回值
func div(a, b int) (int, error) {
    if b == 0 {
        return 0, errors.New("division by zero")
    }
    return a / b, nil
}
// 一次返回多个值
func returnMulti() (int, string) {
    return 42, "foobar"
}
var x, str = returnMulti()
// 可以在函数体中直接对函数返回值进行赋值，在命名的返回值方式的函数体中，在函数结束前需要显式地使用 return 语句进行返回
func returnMulti2() (n int, s string) {
    n = 42
    s = "foobar"
    // n 和 s 会被返回
    return
}
var x, str = returnMulti2()
// 函数作为第一类型，可作为参数或返回值
func test(x int) func() {
    // 匿名函数
    return func() {
        fmt.Println(x)
    }
}

匿名函数（函数作为值和回调使用）

匿名函数语法为：

1
2
3

func(参数列表)(返回参数列表){
    函数体
}

一些示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

// 在定义时调用匿名函数
func(data int) {
    fmt.Println("hello", data)
}(100)
func main() {
    // 将函数作为值，赋给变量
    add := func(a, b int) int {
        return a + b
    }
    // 使用变量直接调用函数
    fmt.Println(add(3, 4))
}
// 使用匿名函数实现操作封装
var skillParam = flag.String("skill", "", "skill to perform")
func main() {
    flag.Parse()
    var skill = map[string]func(){
        "fire": func() {
            fmt.Println("chicken fire")
        },
        "run": func() {
            fmt.Println("soldier run")
        },
        "fly": func() {
            fmt.Println("angel fly")
        },
    }
    if f, ok := skill[*skillParam]; ok {
        f()
    } else {
        fmt.Println("skill not found")
    }
}
// 回调函数作用域：在定义回调函数时能访问外部函数的值
func scope() func() int{
    outer_var := 2
    foo := func() int { return outer_var}
    return foo
}
func another_scope() func() int{
    // 编译错误，两个变量不在此函数作用域内
    // undefined: outer_var
    outer_var = 444
    return foo
}
// 回调函数不会修改外部作用域的数据
func outer() (func() int, int) {
    outer_var := 2
    inner := func() int {
        outer_var += 99 	// 试着使用外部作用域的 outer_var 变量
        return outer_var 	// 返回值是 101，但只在 inner() 内部有效
    }
    return inner, outer_var	// 返回值是 inner, 2 (outer_var 仍是 2）
}
inner, outer_var := outer();	// inner, 2
inner();	// 返回 101
inner();	// 返回 200	// 回调函数的特性

闭包

函数 + 引用环境 = 闭包

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package main
import (
    "fmt"
)
// 创建一个玩家生成器, 输入名称, 输出生成器
func playerGen(name string) func() (string, int) {
    // 血量一直为150
    hp := 150
    // 返回创建的闭包
    return func() (string, int) {
        // 将变量引用到闭包中
        return name, hp
    }
}
func main() {
    // 创建一个玩家生成器
    generator := playerGen("high noon")
    // 返回玩家的名字和血量
    name, hp := generator()
    // 打印值
    fmt.Println(name, hp)
}

可变参数函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

func main() {
	fmt.Println(adder(1, 2, 3)) 	// 6
	fmt.Println(adder(9, 9))	// 18
	
	nums := []int{10, 20, 30}
	fmt.Println(adder(nums...))	// 60
}
// 在函数的最后一个参数类型前，使用 ... 可表明函数还能接收 0 到多个此种类型的参数
// 下边的函数在调用时传多少个参数都可以
func adder(args ...int) int {
	total := 0
	for _, v := range args {	// 使用迭代器逐个访问参数
		total += v
	}
	return total
}

range 函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 迭代数组或 slice
for i, e := range a {
    // i 是索引
    // e 是元素值
}
// 如果你只要值，可用 _ 来丢弃返回的索引
for _, e := range a {
}
// 如果你只要索引
for i := range a {
}
// 在 Go 1.4 以前的版本，如果 i 和 e 你都不用，直接 range 编译器会报错
for range time.Tick(time.Second) {
    // 每隔 1s 执行一次
}

流程控制

if…else…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

//一般的条件判断
x := 1
if x > 0 {
	return x
} else {
	return -x
}
// 在条件判断语句前可以有一条语句
if a := b + c; a < 42 {
	return a
} else {
	return a - 42
}

switch…case…

case 语句自带 break，想执行所有 case 需要手动 fallthrough

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// switch 分支语句
switch arg {
    case "string":
        fmt.Println("string")
    case 1
        fmt.Println("number")
    case arg < 1:
        fmt.Println("运算")
    case case ' ', '?', '&', '=', '#', '+', '%':    // 多个 case 可使用逗号分隔统一处理
        fmt.Println("Should escape")
    default:
        fmt.Println("Other")
}
//  可在判断变量之前加入一条赋值语句
switch os := runtime.GOOS; os {
    case "darwin": ...
}

for

Go 语言中循环结构只有 for，没有 do、while、foreach 等

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

for i := 1; i < 10; i++ {
}
// 等效于 while 循环
for ; i < 10;  {
}
// 只有一个判断条件时可省去分号
for i < 10  {
}
// 无条件循环时，等效于 while(true)
for { 		
}

错误处理

处理运行时错误

Go 中没有异常处理机制，函数在调用时在有可能会产生错误，可返回一个 Error 类型的值，Error 接口：

1
2
3

type error interface {
    Error() string
}

自定义一个错误：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var err = errors.New("this is an error")
// 创建错误对象
func New(text string) error {
    return &errorString{text}
}
// 错误字符串
type errorString struct {
    s string
}
// 返回发生何种错误
func (e *errorString) Error() string {
    return e.s
}

一个可能产生错误的函数：

1
2
3
4
5
6
7
8
9
10

func doStuff() (int, error) {
}
func main() {
    result, err := doStuff()
    if err != nil {
        // 错误处理
    }
    // 使用 result 处理正常逻辑
}

defer(延迟错误处理)

Go语言的 defer 语句会将其后面跟随的语句进行延迟处理，在 defer 归属的函数即将返回时，将延迟处理的语句按 defer 的逆序进行执行，也就是说，先被 defer 的语句最后被执行，最后被 defer 的语句，最先被执行。

关键字 defer 的用法类似于面向对象编程语言 Java 的 finally 语句块，它一般用于释放某些已分配的资源，典型的例子就是对一个互斥解锁，或者关闭一个文件。因为 defer 语句正好是在函数退出时执行的语句，所以使用 defer 能非常方便地处理资源释放问题。

宕机（panic）与宕机恢复（recover）

Go语言的 panic 机制类似于其他语言的异常，但 panic 的适用场景有一些不同，由于 panic 会引起程序的崩溃，因此 panic 一般用于严重错误，如程序内部的逻辑不一致。任何崩溃都表明了我们的代码中可能存在漏洞，所以对于大部分漏洞，我们应该使用Go语言提供的错误机制，而不是 panic。

手动触发宕机： panic("crash")

Recover 是一个Go语言的内建函数，可以让进入宕机流程中的 goroutine 恢复过来，recover 仅在延迟函数 defer 中有效，在正常的执行过程中，调用 recover 会返回 nil 并且没有其他任何效果，如果当前的 goroutine 陷入恐慌，调用 recover 可以捕获到 panic 的输入值，并且恢复正常的执行。

panic 和 recover 的关系

panic 和 recover 的组合有如下特性：

• 有 panic 没 recover，程序宕机。
• 有 panic 也有 recover，程序不会宕机，执行完对应的 defer 后，从宕机点退出当前函数后继续执行。

提示

虽然 panic/recover 能模拟其他语言的异常机制，但并不建议在编写普通函数时也经常性使用这种特性。

在 panic 触发的 defer 函数内，可以继续调用 panic，进一步将错误外抛，直到程序整体崩溃。

如果想在捕获错误时设置当前函数的返回值，可以对返回值使用命名返回值方式直接进行设置。

OOP

对象

见 struct

继承

Go语言中的继承是通过内嵌或组合来实现的

• 1) 内嵌的结构体可以直接访问其成员变量
• 2) 内嵌结构体的字段名是它的类型名

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

package main
import "fmt"
// 可飞行的
type Flying struct{}
func (f *Flying) Fly() {
    fmt.Println("can fly")
}
// 可行走的
type Walkable struct{}
func (f *Walkable) Walk() {
    fmt.Println("can calk")
}
// 人类
type Human struct {
    Walkable // 人类能行走
}
// 鸟类
type Bird struct {
    Walkable // 鸟类能行走
    Flying   // 鸟类能飞行
}
func main() {
    // 实例化鸟类
    b := new(Bird)
    fmt.Println("Bird: ")
    b.Fly()
    b.Walk()
    // 实例化人类
    h := new(Human)
    fmt.Println("Human: ")
    h.Walk()
}

构造方法

Go语言的类型或结构体没有构造函数的功能，但是我们可以使用结构体初始化的过程来模拟实现构造函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

//多种方式创建和初始化结构体——模拟构造函数重载
type Cat struct {
    Color string
    Name  string
}
func NewCatByName(name string) *Cat {
    return &Cat{ //定义用名字构造猫结构的函数，返回 Cat 指针。
        Name: name,
    }
}
func NewCatByColor(color string) *Cat {
    return &Cat{    //定义用颜色构造猫结构的函数，返回 Cat 指针。
        Color: color,
    }
}
//带有父子关系的结构体的构造和初始化——模拟父级构造调用
type BlackCat struct {
    Cat  // 嵌入Cat, 类似于继承
}
// “构造基类”
func NewCat(name string) *Cat {
    return &Cat{
        Name: name,
    }
}
// “构造子类”
func NewBlackCat(color string) *BlackCat {
    cat := &BlackCat{}
    cat.Color = color
    return cat
}

方法

Go 方法是作用在接收器（receiver）上的一个函数，接收器是某种类型的变量，因此方法是一种特殊类型的函数。

接收器语法格式：

1
2
3

func (接收器变量 接收器类型) 方法名(参数列表) (返回参数) {
    函数体
}

对各部分的说明：

• 接收器变量：接收器中的参数变量名在命名时，官方建议使用接收器类型名的第一个小写字母，而不是 self、this 之类的命名。例如，Socket 类型的接收器变量应该命名为 s，Connector 类型的接收器变量应该命名为 c 等。
• 接收器类型：接收器类型和参数类似，可以是指针类型和非指针类型。
• 方法名、参数列表、返回参数：格式与函数定义一致。

接收器根据接收器的类型可以分为指针接收器、非指针接收器，两种接收器在使用时会产生不同的效果，根据效果的不同，两种接收器会被用于不同性能和功能要求的代码中。

指针接收器

指针类型的接收器由一个结构体的指针组成，更接近于面向对象中的 this 或者 self。

由于指针的特性，调用方法时，修改接收器指针的任意成员变量，在方法结束后，修改都是有效的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

package main
import "fmt"
// 定义属性结构
type Property struct {
    value int  // 属性值
}
// 设置属性值
func (p *Property) SetValue(v int) {
    // 修改p的成员变量
    p.value = v
}
// 取属性值
func (p *Property) Value() int {
    return p.value
}
func main() {
    // 实例化属性
    p := new(Property)
    // 设置值
    p.SetValue(100)
    // 打印值
    fmt.Println(p.Value())
}

非指针接收器

当方法作用于非指针接收器时，Go语言会在代码运行时将接收器的值复制一份，在非指针接收器的方法中可以获取接收器的成员值，但修改后无效。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

package main
import (
    "fmt"
)
// 定义点结构
type Point struct {
    X int
    Y int
}
// 非指针接收器的加方法
func (p Point) Add(other Point) Point {
    // 成员值与参数相加后返回新的结构
    return Point{p.X + other.X, p.Y + other.Y}
}
func main() {
    // 初始化点
    p1 := Point{1, 1}
    p2 := Point{2, 2}
    // 与另外一个点相加
    result := p1.Add(p2)
    // 输出结果
    fmt.Println(result)
}

指针和非指针接收器的使用

• 在计算机中，小对象由于值复制时的速度较快，所以适合使用非指针接收器，大对象因为复制性能较低，适合使用指针接收器，在接收器和参数间传递时不进行复制，只是传递指针。

• 不管你的method的receiver是指针类型还是非指针类型，都是可以通过指针/非指针类型进行调用的，编译器会帮你做类型转换。

• 在声明一个method的receiver该是指针还是非指针类型时，你需要考虑两方面的内部，第一方面是这个对象本身是不是特别大，如果声明为非指针变量时，调用会产生一次拷贝；第二方面是如果你用指针类型作为receiver，那么你一定要注意，这种指针类型指向的始终是一块内存地址，就算你对其进行了拷贝。熟悉C或者C艹的人这里应该很快能明白。

接口

接口是用来定义行为的类型，这些被定义的行为不由接口直接实现，而是通过方法由用户定义的类型实现。Go 接口实现机制很简洁，只要目标类型方法包含接口声明的全部方法，就被视为实现了该接口，无需做显示声明。当然，目标类可以实现多个接口。如果接口没有任何方法声明，那么就是一个空接口（interface{}），它的用途类似 Object，可被赋值为任何类型的对象。

1
2
3
4
5
6
7
8
9
10
11
12

// 声明接口
type Awesomizer interface {
    Awesomize() string
}
// 无需手动声明 implement 接口
type Foo struct {}
// 自定义类型如果实现了接口的所有方法，那它就自动实现了该接口
func (foo Foo) Awesomize() string {
    return "Awesome!"
}

类型断言（Type Assertion）是一个使用在接口值上的操作，用于检查接口类型变量所持有的值是否实现了期望的接口或者具体的类型。

value, ok := x.(T)

其中，x 表示一个接口的类型，T 表示一个具体的类型（也可为接口类型）。

该断言表达式会返回 x 的值（也就是 value）和一个布尔值（也就是 ok），可根据该布尔值判断 x 是否为 T 类型：

• 如果 T 是具体某个类型，类型断言会检查 x 的动态类型是否等于具体类型 T。如果检查成功，类型断言返回的结果是 x 的动态值，其类型是 T。
• 如果 T 是接口类型，类型断言会检查 x 的动态类型是否满足 T。如果检查成功，x 的动态值不会被提取，返回值是一个类型为 T 的接口值。
• 无论 T 是什么类型，如果 x 是 nil 接口值，类型断言都会失败。

并发

goroutine

goroutine 是 Go语言中的轻量级线程实现，由 Go 运行时（runtime）管理。Go 程序会智能地将 goroutine 中的任务合理地分配给每个 CPU。

Go 程序从 main 包的 main() 函数开始，在程序启动时，Go 程序就会为 main() 函数创建一个默认的 goroutine。

使用普通函数创建 goroutine：

Go 程序中使用 go 关键字为一个函数创建一个 goroutine。一个函数可以被创建多个 goroutine，一个 goroutine 必定对应一个函数。语法：go 函数名( 参数列表 )。使用 go 关键字创建 goroutine 时，被调用函数的返回值会被忽略。如果需要在 goroutine 中返回数据，请使用后面介绍的通道（channel）特性，通过通道把数据从 goroutine 中作为返回值传出。

也可以使用匿名函数创建：

1
2
3

go func( 参数列表 ){
    函数体
}( 调用参数列表 )

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package main
import (
	"fmt"
	"time"
)
func running() {
	var times int
	// 构建一个无限循环
	for {
		times++
		fmt.Println("tick", times)
		// 延时1秒
		time.Sleep(time.Second)
	}
}
func main() {
	// 并发执行程序
	go running()
	// 接受命令行输入, 不做任何事情
	var input string
	fmt.Scanln(&input)
}

反射

Go语言提供了一种机制，能够在运行时更新变量和检查它们的值、调用它们的方法和它们支持的内在操作，而不需要在编译时就知道这些变量的具体类型。这种机制被称为反射。

反射是由 reflect 包提供的。 它定义了两个重要的类型, Type 和 Value。

• 一个 Type 表示一个Go类型。函数 reflect.TypeOf 接受任意的 interface{} 类型, 并以reflect.Type形式返回其动态类型
• 一个 reflect.Value 可以装载任意类型的值。函数 reflect.ValueOf 接受任意的 interface{} 类型, 并返回一个装载着其动态值的 reflect.Value。

标题：Golang 之禅

地址：https://www.oschina.net/news/113606/the-zen-of-go

在本月初的 GopherCon 上，知名 Go 语言贡献者与布道师 Dave Cheney 发表了名为《The Zen of Go》的演讲，之后他整理了演讲内容在博客中分享，由于内容过长，他又写了一个简洁版本：

完整版：https://dave.cheney.net/2020/02/23/the-zen-of-go
简洁版：https://the-zen-of-go.netlify.com
这里简单翻译一下简洁版本的内容：

编写简单、可读、可维护的 Go 代码的十个工程要点。

每个包实现单一目标

设计良好的 Go 软件包提供一个单一的思路，以及一系列相关的行为。一个好的 Go 软件包首先需要选择一个好名字，使用电梯法则（30 秒内向客户讲清楚一个方案），仅用一个词来思考你的软件包要提供什么功能。

明确处理错误

健壮的程序其实是由处理故障案例的片段组成的，并且需要在故障出现之前处理好。冗余的if err != nil { return err }比出了故障再一个个去处理更有价值。panic 和 recover 也一样。

尽早 return，不要深陷

每次缩进时都会在程序员的堆栈中添加另一个先决条件，这会占用他们短期内存中的 7±2 个片段。避免需要深层缩进的控制流。与其深入嵌套，不如使用守卫子句将成功路径保持在左侧。

并发权留给调用者

让调用者选择是否要异步运行你的库或函数，不要强制他们使用异步。

在启动 goroutine 之前，要知道它什么时候会停止

goroutines 拥有资源、锁、变量与内存等，释放这些资源的可靠方法是停止 goroutine。

避免包级别的状态

要完成明确和减少耦合的操作，需要通过提供类型需要的依赖项作为该类型上的字段，而不是使用包变量。

简单性很重要

简单性不是老练的代名词。简单并不意味着粗糙，它意味着可读性和可维护性。如果可以选择，请遵循较简单的解决方案。

编写测试以确认包 API 的行为

软件包的 API 是与使用者的一份合约，不管先后，不管多少，一定要进行测试。测试是确定合约的保证。要确保测试使用者可以观察和依赖的行为。

如果你认为速度缓慢，先通过基准测试进行验证

以性能之名会犯下许多危害可维护性的罪行。优化会破坏抽象、暴露内部和紧密耦合。如果要付出这样的代价，请确保有充分理由这样做。

节制是一种美德

适度使用 goroutine、通道、锁、接口与嵌套。

在使用 Python 的时候，logging 一度让我头疼。因为，从 Java 转过来以后，总是想着 logback、log4j 那样的统一配置。在使用过程中折腾了些时候，算是勉强给出了自己比较满意的效果。

logging 使用

日志的简单使用可以参考官方的《日志操作手册》

其他的学习资料有：

• Python 日志模块
• python logging日志模块以及多进程日志
• Python之日志处理（logging模块）

我的 logging 配置

我的 logging 配置主要基于 Tornado 的日志模块进行了修改。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261

# coding=utf-8
"""
基于Tornado Log的logger实现.
"""
import logging
import logging.handlers
import os
import sys
from typing import Dict, Any, cast, Union, Optional
bytes_type = bytes
unicode_type = str
basestring_type = str
try:
    import colorama  # type: ignore
except ImportError:
    colorama = None
try:
    import curses
except ImportError:
    curses = None  # type: ignore
_TO_UNICODE_TYPES = (unicode_type, type(None))
def _unicode(value: Union[None, str, bytes]) -> Optional[str]:  # noqa: F811
    """Converts a string argument to a unicode string.
    If the argument is already a unicode string or None, it is returned
    unchanged.  Otherwise it must be a byte string and is decoded as utf8.
    """
    if isinstance(value, _TO_UNICODE_TYPES):
        return value
    if not isinstance(value, bytes):
        raise TypeError("Expected bytes, unicode, or None; got %r" % type(value))
    return value.decode("utf-8")
def _stderr_supports_color() -> bool:
    try:
        if hasattr(sys.stderr, "isatty") and sys.stderr.isatty():
            if curses:
                curses.setupterm()
                if curses.tigetnum("colors") > 0:
                    return True
            elif colorama:
                if sys.stderr is getattr(
                        colorama.initialise, "wrapped_stderr", object()
                ):
                    return True
    except Exception:
        # Very broad exception handling because it's always better to
        # fall back to non-colored logs than to break at startup.
        pass
    return False
def _safe_unicode(s: Any) -> str:
    try:
        return _unicode(s)
    except UnicodeDecodeError:
        return repr(s)
class LogFormatter(logging.Formatter):
    """
    Log formatter used in Tornado.
    """
    DEFAULT_FORMAT = "%(color)s[%(levelname)1.1s %(asctime)s %(module)s:%(lineno)d]%(end_color)s %(message)s"  # noqa: E501
    DEFAULT_DATE_FORMAT = "%Y-%m-%d %H:%M:%S"
    DEFAULT_COLORS = {
        logging.DEBUG: 4,  # Blue
        logging.INFO: 2,  # Green
        logging.WARNING: 3,  # Yellow
        logging.ERROR: 1,  # Red
    }
    def __init__(
            self,
            fmt: str = DEFAULT_FORMAT,
            datefmt: str = DEFAULT_DATE_FORMAT,
            color: bool = True,
            colors: Dict[int, int] = DEFAULT_COLORS,
    ) -> None:
        r"""
        :arg bool color: Enables color support.
        :arg str fmt: Log message format.
          It will be applied to the attributes dict of log records. The
          text between ``%(color)s`` and ``%(end_color)s`` will be colored
          depending on the level if color support is on.
        :arg dict colors: color mappings from logging level to terminal color
          code
        :arg str datefmt: Datetime format.
          Used for formatting ``(asctime)`` placeholder in ``prefix_fmt``.
        """
        logging.Formatter.__init__(self, datefmt=datefmt)
        self._fmt = fmt
        self._colors = {}  # type: Dict[int, str]
        if color and _stderr_supports_color():
            if curses is not None:
                fg_color = curses.tigetstr("setaf") or curses.tigetstr("setf") or b""
                for levelno, code in colors.items():
                    # Convert the terminal control characters from
                    # bytes to unicode strings for easier use with the
                    # logging module.
                    self._colors[levelno] = unicode_type(
                        curses.tparm(fg_color, code), "ascii"
                    )
                self._normal = unicode_type(curses.tigetstr("sgr0"), "ascii")
            else:
                # If curses is not present (currently we'll only get here for
                # colorama on windows), assume hard-coded ANSI color codes.
                for levelno, code in colors.items():
                    self._colors[levelno] = "\033[2;3%dm" % code
                self._normal = "\033[0m"
        else:
            self._normal = ""
    def format(self, record: Any) -> str:
        try:
            message = record.getMessage()
            assert isinstance(message, basestring_type)  # guaranteed by logging
            record.message = _safe_unicode(message)
        except Exception as e:
            record.message = "Bad message (%r): %r" % (e, record.__dict__)
        record.asctime = self.formatTime(record, cast(str, self.datefmt))
        if record.levelno in self._colors:
            record.color = self._colors[record.levelno]
            record.end_color = self._normal
        else:
            record.color = record.end_color = ""
        formatted = self._fmt % record.__dict__
        if record.exc_info:
            if not record.exc_text:
                record.exc_text = self.formatException(record.exc_info)
        if record.exc_text:
            lines = [formatted.rstrip()]
            lines.extend(_safe_unicode(ln) for ln in record.exc_text.split("\n"))
            formatted = "\n".join(lines)
        return formatted.replace("\n", "\n    ")
class NullHandler(logging.Handler):
    def emit(self, record):
        pass
class ExactLogLevelFilter(logging.Filter):
    def __init__(self, level):
        self.__level = level
    def filter(self, log_record):
        return log_record.levelno == self.__level
def _pretty_logging(options: Dict, logger: logging.Logger) -> None:
    # 如果没有设置日志级别
    if options['logging_level'] is None or options['logging_level'].lower() == "none":
        return
    if options['log_file_path']:
        rotate_mode = options['log_rotate_mode']
        if rotate_mode == "size":
            channel = logging.handlers.RotatingFileHandler(
                filename=options['log_file_path'],
                maxBytes=options['log_file_max_size'],
                backupCount=options['log_file_num_backups'],
                encoding="utf-8",
            )  # type: logging.Handler
        elif rotate_mode == "time":
            channel = logging.handlers.TimedRotatingFileHandler(
                filename=options['log_file_path'],
                when=options['log_rotate_when'],
                interval=options['log_rotate_interval'],
                backupCount=options['log_file_num_backups'],
                encoding="utf-8",
            )
        else:
            error_message = (
                    "The value of log_rotate_mode option should be "
                    + '"size" or "time", not "%s".' % rotate_mode
            )
            raise ValueError(error_message)
        channel.setFormatter(LogFormatter(color=False))
        # 添加通过级别过滤
        channel.addFilter(ExactLogLevelFilter(logging.getLevelName(options['logging_level'])))
        logger.addHandler(channel)
    if options['log_to_stderr'] or (options['log_to_stderr'] is None and not logger.handlers):
        # Set up color if we are in a tty and curses is installed
        channel = logging.StreamHandler()
        channel.setFormatter(LogFormatter())
        logger.addHandler(channel)
def initialize_logging(logger: logging.Logger = None, options: Dict = None):
    """
    :param logger:
    :param options:
        {
        'log_file_path':'日志文件路径',
        'logging_level':'日志级别（DEBUG/INFO/WARN/ERROR）',
        'log_to_stderr':'将日志输出发送到stderr（如果可能的话，将其着色）。如果未设置--log_file_prefix并且未配置其他日志记录，则默认使用stderr。',
        'log_file_max_size':'每个文件最大的大小，默认：100 * 1000 * 1000',
        'log_file_num_backups':'要保留的日志文件数',
        'log_rotate_when':'时间间隔的类型（'S', 'M', 'H', 'D', 'W0'-'W6'）',
        'log_rotate_interval':'TimedRotatingFileHandler的interval值',
        'log_rotate_mode':'类型（size/time）'
        }
    :return:
    """
    if logger is None:
        logger = logging.getLogger()
    if options is None:
        options = {}
    default_options = {
        'log_file_path': '',
        'logging_level': 'INFO',
        'log_to_stderr': None,
        'log_file_max_size': 100 * 1000 * 1000,
        'log_file_num_backups': 10,
        'log_rotate_when': 'M',
        'log_rotate_interval': 1,
        'log_rotate_mode': 'time'
    }
    default_options.update(options)
    # 设置日志级别
    logger.setLevel(getattr(logging, default_options['logging_level'].upper()))
    log_level_path = {
        'DEBUG': os.path.join(default_options['log_file_path'], 'debug/debug.log'),
        'INFO': os.path.join(default_options['log_file_path'], 'info/info.log'),
        'WARNING': os.path.join(default_options['log_file_path'], 'warning/warning.log'),
        'ERROR': os.path.join(default_options['log_file_path'], 'error/error.log')
    }
    log_levels = log_level_path.keys()
    for level in log_levels:
        log_path = os.path.abspath(log_level_path[level])
        if not os.path.exists(os.path.dirname(log_path)):
            os.makedirs(os.path.dirname(log_path))
        default_options.update({'log_file_path': log_path, 'logging_level': level})
        _pretty_logging(options=default_options, logger=logger)

以上的代码没有考虑到多线程情况下的使用场景，且暂时考虑的是在应用程序中使用的场景。

AES 是 Advanced Encryption Standard 的缩写，也就是 高级加密标准 。具体可以见：高级加密标准。本文主要讨论使用 Java SDK中对 AES 的实现。

从 JDK 的 Cipher 文档 中，知道它支持 4 种 AES 加密模式：

• AES/CBC/NoPadding (128)
• AES/CBC/PKCS5Padding (128)
• AES/ECB/NoPadding (128)
• AES/ECB/PKCS5Padding (128)

AES 是一种加解密算法，那么 CBC, ECB, NoPadding 和 PKCS5Padding 是什么呢？

CBC, CBC 是分组密码工作模式，是对于按块处理密码的加密方式的一种扩充。NoPadding, PKCS5Padding 是填充(Padding)，是对需要按块处理的数据，当数据长度不符合块处理需求时，按照一定方法填充满块长的一种规则。

关于分组密码工作模式，可以参考： 分组密码工作模式 和 AES五种加密模式（CBC、ECB、CTR、OCF、CFB）
关于填充，可以参考：Padding (cryptography)

参考，JAVA AES算法 知道（以下部分的内容为该文章里的内容）：

• (1)缺省模式和填充为“AES/ECB/PKCS5Padding”，Cipher.getInstance(“AES”)与Cipher.getInstance(“AES/ECB/PKCS5Padding”)等效。
• (2)JDK的PKCS5Padding实际是上述的PKCS7的实现。
• (3)由于AES是按照16Byte为块进行处理，对于NoPadding而言，如果需要加密的原文长度不是16Byte的倍数，将无法处理抛出异常，其实是由用户自己选择Padding的算法。密文则必然是16Byte的倍数，否则密文肯定异常。
• (4)如果加密为PKCS5Padding，解密可以选择NoPadding，也能解密成功，内容为原文加上PKCS5Padding之后的结果。
• (5)如果原文最后一个字符为>=0x00&&<=0x10的内容，PKCS5Padding的解密将会出现异常，要么是符合PKCS5Padding，最后的内容被删除，要么不符合，则解密失败抛出异常。对此有两种思路，一是原文通过Base64编码为可见字符，二是原文自带长度使用NoPadding解密。

代码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;
public class AesUtil {
    /**
     * AES/CBC/PKCS5Padding加密，然后进行base64加密
     *
     * @param plainText
     * @param key
     * @return
     * @throws Exception
     */
    public static String encryptBase64AESCBC(String plainText, String key) throws Exception {
        byte[] clean = plainText.getBytes();
        //Cipher
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        // Generating IV.
        int ivSize = cipher.getBlockSize();
        byte[] iv = new byte[ivSize];
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv);
        IvParameterSpec ivParameterSpec = new IvParameterSpec(iv);
        // Encrypt.
        SecretKeySpec secretKeySpec = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
        cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec);
        byte[] encrypted = cipher.doFinal(clean);
        // Combine IV and encrypted part.
        byte[] encryptedIVAndText = new byte[ivSize + encrypted.length];
        System.arraycopy(iv, 0, encryptedIVAndText, 0, ivSize);
        System.arraycopy(encrypted, 0, encryptedIVAndText, ivSize, encrypted.length);
        return Base64.getEncoder().encodeToString(encryptedIVAndText);
    }
    /**
     * base64解密后再进行AES/CBC/PKCS5Padding解密
     *
     * @param encryptedIvText
     * @param key
     * @return
     * @throws Exception
     */
    public static String decryptBase64AESCBC(String encryptedIvText, String key) throws Exception {
        byte[] encryptedIvTextBytes = Base64.getDecoder().decode(encryptedIvText);
        //Cipher
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        // Extract IV.
        int ivSize = cipher.getBlockSize();
        byte[] iv = new byte[ivSize];
        System.arraycopy(encryptedIvTextBytes, 0, iv, 0, iv.length);
        IvParameterSpec ivParameterSpec = new IvParameterSpec(iv);
        // Extract encrypted part.
        int encryptedSize = encryptedIvTextBytes.length - ivSize;
        byte[] encryptedBytes = new byte[encryptedSize];
        System.arraycopy(encryptedIvTextBytes, ivSize, encryptedBytes, 0, encryptedSize);
        // Decrypt.
        SecretKeySpec secretKeySpec = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
        cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec);
        byte[] original = cipher.doFinal(encryptedBytes);
        String originalString = new String(original);
        return originalString;
    }
}

以上代码中 iv的长度为 cipher.getBlockSize()，然后将 iv 放在加密文本的前部分。解密的时候一样先获得 iv，再进行加密内容的解密。

基本使用

SpringBoot 2.x项目中引入spring-boot-starter-data-redis：

1
2
3
4

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

查看引入包，发现SpringBoot 2.x 使用的是： lettuce 。

配置 application.yml

1
2
3
4
5
6

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    password:
    database: 0

使用：

1
2
3
4
5

@Autowired
private RedisTemplate<String, String> redisTemplate;
@Autowired
private StringRedisTemplate stringRedisTemplate;

SpringBoot Redis的自动化配置位于：RedisAutoConfiguration

多Redis数据源配置

项目中常常用到不止一个Redis数据源，如果按照上面的简单配置，那么很难满足需要。需要我们自己来声明 ConnectionFactory 和 RedisTemplate 。

application.yml中配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

spring:
  redis:  #redis配置
    redis-a:
      host: 127.0.0.1
      port: 6379
      password: pwd@local
      ssl: true
      database: 0
    redis-b:
      host: 127.0.0.1
      port: 6479
      password: pwd@local
      ssl: true
      database: 0

以上配置是在spring.redis下做区分两个数据源，这是为了能够方便地查找配置位置。

添加RedisConfig.java，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

@Configuration
public class RedisConfig {
    @Bean(name = "aRedisTemplate")
    public StringRedisTemplate aRedisTemplate(
            @Qualifier("aLettuceConnectionFactory") RedisConnectionFactory aLettuceConnectionFactory) {
        StringRedisTemplate template = new StringRedisTemplate();
        template.setConnectionFactory(aLettuceConnectionFactory);
        return template;
    }
    @Bean(name = "bRedisTemplate")
    public StringRedisTemplate bRedisTemplate(
            @Qualifier("bConnectionFactory") RedisConnectionFactory bConnectionFactory) {
        StringRedisTemplate template = new StringRedisTemplate();
        template.setConnectionFactory(bConnectionFactory);
        return template;
    }
    @Bean(name = "aLettuceConnectionFactory")
    @Primary
    public LettuceConnectionFactory aLettuceConnectionFactory(@Value("${spring.redis.redis-a.host}") String host,
                                                                   @Value("${spring.redis.redis-a.port}") int port,
                                                                   @Value("${spring.redis.redis-a.password}") String password,
                                                                   @Value("${spring.redis.redis-a.ssl}") boolean ssl,
                                                                   @Value("${spring.redis.redis-a.database}") int database) {
        LettuceClientConfiguration.LettuceClientConfigurationBuilder builder = LettuceClientConfiguration.builder();
        if (ssl) {
            builder.useSsl();
        }
        RedisStandaloneConfiguration standaloneConfiguration = getRedisStandaloneConfiguration(host, port, password, database);
        return new LettuceConnectionFactory(standaloneConfiguration, builder.build());
    }
    @Bean(name = "bConnectionFactory")
    public LettuceConnectionFactory bConnectionFactory(@Value("${spring.redis.redis-b.host}") String host,
                                                                   @Value("${spring.redis.redis-b.port}") int port,
                                                                   @Value("${spring.redis.redis-b.password}") String password,
                                                                   @Value("${spring.redis.redis-b.ssl}") boolean ssl,
                                                                   @Value("${spring.redis.redis-b.database}") int database) {
        LettuceClientConfiguration.LettuceClientConfigurationBuilder builder = LettuceClientConfiguration.builder();
        if (ssl) {
            builder.useSsl();
        }
        RedisStandaloneConfiguration standaloneConfiguration = getRedisStandaloneConfiguration(host, port, password, database);
        return new LettuceConnectionFactory(standaloneConfiguration, builder.build());
    }
    private RedisStandaloneConfiguration getRedisStandaloneConfiguration(String host, int port, String password, int database) {
        RedisStandaloneConfiguration standaloneConfiguration = new RedisStandaloneConfiguration();
        standaloneConfiguration.setHostName(host);
        standaloneConfiguration.setPort(port);
        standaloneConfiguration.setPassword(password);
        standaloneConfiguration.setDatabase(database);
        return standaloneConfiguration;
    }
}

使用：

1
2
3
4
5
6
7
8
9

@Autowired
@Qualifier("aRedisTemplate")
private StringRedisTemplate aRedisTemplate;
@Autowired
@Qualifier("bRedisTemplate")
private StringRedisTemplate bRedisTemplate;

如果想要忽略掉默认的Redis配置，那么可以将 RedisAutoConfiguration 和 RedisReactiveAutoConfiguration 加入忽略：

1

@EnableAutoConfiguration(exclude = {RedisAutoConfiguration.class, RedisReactiveAutoConfiguration.class})

准备工作

安装 Node.js 、安装以太节点以及合约代码等与web3.js编译Solidity，发布，调用全部流程（手把手教程）中的一致。

• 安装好的NodeJs版本为：v10.15.3
• 安装好的以太节点版本为：ethereumjs-testrpc@6.0.3

遇到的坑

第一个坑：Solidity安装

按照官方文档使用 npm install -g solc 安装。

安装后验证版本应该使用 solcjs --version ，而不是 solc --version 。而且这边安装的是最新版本，也为后面的步骤埋下了坑。

第二个坑：TypeError: Cannot read property ‘solidity’ of undefined

使用以下代码：

1
2

let source = "pragma solidity ^0.4.0;contract Calc{  /*区块链存储*/  uint count;  /*执行会写入数据，所以需要`transaction`的方式执行。*/  function add(uint a, uint b) returns(uint){    count++;    return a + b;  }  /*执行不会写入数据，所以允许`call`的方式执行。*/  function getCount() returns (uint){    return count;  }}";
let calc = web3.eth.compile.solidity(source);

运行的时候报：

1
2
3
4
5
6
7
8
9
10
11
12
13

let calc = web3.eth.compile.solidity(source);
                            ^
TypeError: Cannot read property 'solidity' of undefined
    at Object.<anonymous> (/data/eth-contract/src/index.js:15:29)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

这个是因为 Geth 在 1.5.9 版本以后就不支持此功能。见：Ethereum Dapp初心者之路(7): web3.eth.compile.solidity()替代方案。

所以参考 https://ethereum.stackexchange.com/questions/6346/solc-version-command-not-found 文章，将代码改为：

1
2
3
4

const fs = require("fs");
const solc = require('solc');
let source = fs.readFileSync('Calc.sol', 'UTF-8');
let compilationData = solc.compile(source);

第三个坑：编译报错

编译的时候，如果遇到以下报错：

1

{"errors":[{"component":"general","formattedMessage":"* Line 1, Column 1\n  Syntax error: value, object or array expected.\n* Line 1, Column 2\n  Extra non-whitespace after JSON value.\n","message":"* Line 1, Column 1\n  Syntax error: value, object or array expected.\n* Line 1, Column 2\n  Extra non-whitespace after JSON value.\n","severity":"error","type":"JSONError"}]}

这个是因为 solc 的版本不对，我们的代码中的版本是 ^0.4.0 ，而安装的 solc 的版本为 ^0.5.7 。应该用一样的版本。

代码中的版本改为^0.5.7，即pragma solidity ^0.5.7;。运行后，报：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

assert.js:350
    throw err;
    ^
AssertionError [ERR_ASSERTION]: Invalid callback specified.
    at wrapCallback (/data/eth-contract/node_modules/solc/wrapper.js:16:5)
    at runWithReadCallback (/data/eth-contract/node_modules/solc/wrapper.js:42:26)
    at compileStandard (/data/eth-contract/node_modules/solc/wrapper.js:83:14)
    at Object.compileStandardWrapper (/data/eth-contract/node_modules/solc/wrapper.js:90:14)
    at Object.<anonymous> (/data/eth-contract/src/index.js:8:28)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

参考 https://stackoverflow.com/questions/53353167/npm-solc-assertionerror-err-assertion-invalid-callback-specified 后，如下操作：

1
2
3

npm uninstall -g solc
npm uninstall solc
npm install solc@0.4.25

然后将代码中的版本号改为：pragma solidity ^0.4.25;

完整源码

index.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

const Web3 = require('web3');
const fs = require("fs");
const solc = require('solc');
let web3;
if (typeof web3 !== 'undefined') {
    web3 = new Web3(web3.currentProvider);
} else {
    // set the provider you want from Web3.providers
    web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
}
//编译合约
let source = fs.readFileSync('Calc.sol', 'UTF-8').toString();
let calcCompiled = solc.compile(source);
//得到合约对象
let jsonInterface = calcCompiled['contracts'][':Calc']['interface'];
//获得abi
let abi = JSON.parse(jsonInterface);
//获取合约的代码
let bytecode = calcCompiled['contracts'][':Calc']['bytecode']
//得到合约对象
const calcContract = new web3.eth.Contract(abi,null,{
    data: '0x'+bytecode, 
    defaultGas:'4700000'
});
//部署者的地址，当前取默认账户的第一个地址
let deployeAddr = web3.eth.accounts[0];
//部署合约
calcContract.deploy().send({
    from: deployeAddr
})
.on('error', (error) => { 
    console.error(error)
 })
.on('transactionHash', (transactionHash) => { 
    console.log("transactionHash :" + transactionHash)
 })
.on('receipt', (receipt) => {
   console.log("receipt:") 
   console.log(receipt) 
})
.on('confirmation', (confirmationNumber, receipt) => { 
   console.log("confirmationNumber:"+confirmationNumber)
 }).then((newContractInstance) => {
    console.log(newContractInstance)
    console.log(newContractInstance.options.address) // instance with the new contract address
});

Calc.sol:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

pragma solidity ^0.4.25;
contract Calc{
  /*区块链存储*/
  uint count;
  /*执行会写入数据，所以需要`transaction`的方式执行。*/
  function add(uint a, uint b) returns(uint){
    count++;
    return a + b;
  }
  /*执行不会写入数据，所以允许`call`的方式执行。*/
  function getCount() constant returns (uint){
    return count;
  }
}

package.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "name": "eth-contract",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "solc": "^0.4.25",
    "web3": "^1.0.0-beta.52"
  }
}

参考

• web3.js编译Solidity，发布，调用全部流程（手把手教程）
• web3.js - Ethereum JavaScript API
• Solidity 开发指南
• Remix - Solidity IDE

闪电网络是什么

官方网站：http://lightning.network/

闪电网络（Lightning Network）是一个去中心化的系统。闪电网络的卓越之处在于，无需信任对方以及第三方即可实现实时的、海量的交易网络。这也就解决了比特币支付存在着拥堵的问题。

闪电网络是基于微支付通道演进而来，创造性的设计出了两种类型的交易合约：序列到期可撤销合约RSMC（Revocable Sequence Maturity Contract），哈希时间锁定合约HTLC（Hashed Timelock Contract）。

RSMC解决了通道中币单向流动问题，也就是链下交易的确认问题；HTLC解决了币跨节点传递的问题，也就是支付通道问题。这两个类型的交易组合构成了闪电网络。

1. 入门级文字：

• 用大白话解释：闪电网络是什么？
• 闪电网络详解
• 闪电网络入门：什么是闪电网络？它是如何运作的？
• 什么是闪电网络？干货都在这了！
• 区块链学堂——闪电网络是什么鬼（故事篇）？
• 区块链学堂——闪电网络是个什么鬼（技术篇）？

2. 如果不喜欢文字资料，还可以通过以下两个视频简单入门：

• 中心化魔鬼or 扩容灵药，6分钟带你看懂闪电网络！
• 闪电网络五大误区，你踩雷了吗？

3. 白皮书：

• 比特币闪电网络白皮书：可扩展的 off-chain 即时支付
• The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments

4. 其他资料：

• BITCOIN LIGHTNING NETWORK - Resource and Information Guide

闪电网络的优缺点

闪电网络的优点

• 可以即时支付
• 对节点的性能需求并不高
• 通过路由系统自动寻径(寻找花费最少的路径)，网络中的节点充分竞争使得交易费用可以低
• 匿名性(每一个节点只记录该通道内的交易)

闪电网络的缺点

• 如果换一种代币就需要重新开启通道，节点和用户的成本都相当的高
• 没有足够的商家支持闪电网络，使得作为节点的收益并不高，由于没有足够的商家支持，用户使用闪电网络的需求并不高
• 闪电网络是小额支付，开启通道是需要使用公网的，使用公网意味着要发起一次交易，如果只转入几百块，一次交易就需要几十块，可能就得不偿失了
• 关闭通道时,也需要发起交易，将通道中的币分配给通道以及用户，这又需要发起一次交易，又需要发起一次交易
• 其次每个节点都需要抵押一定的比特币，才能开启节点，长时间暴露在公网中，可能会存在私钥泄露的问题
• 现阶段闪电网络并不完善处于一个初始版本

闪电网络的浏览器

• 1ML
• Lightning network explorer
• Lightblock
• Robtex Bitcoin Lightning Explorer
• Lightning Explorer (explore casa)
• lndexplorer
• Lightning Explorerc(chaintools)
• Bitcoin Visuals
• rompert.com
• Bitcoin Exchange Rate

其他：

• lngraph - Personal private Lightning Network explorer using Neo4j Browser
• A (mostly) visual collection of the Lightning Network

闪电网络的钱包

闪电网络的钱包可以参考Lightning mobile wallets列表。

GitHub上开源的钱包项目：

桌面

• lightning-app - NodeJs实现
• lnd-gui - Swift实现
• eclair-node-gui - Java实现
• zap-desktop - Electron+React+Redux实现
• Presto - C++实现
• Lightning Peach Wallet - Electron+React+Redux实现
• spark-wallet - NodeJs实现

Web

• Discovery wallet - NodeJs实现
• fulmo - Python实现
• kugelblitz - Go实现
• lncli-web - NodeJS+Angular实现
• Ride The Lightning (RTL) - NodeJS+Angular7实现

移动端

可以参考Lightning mobile wallets中Open source为yes的项目。

闪电网络协议的实现

在闪电网络的实现方面，现在比较主流的有Lightning Network Daemon、eclair和c-lightning。这三个实现是兼容的。

Lightning Network Daemon (LND)

LND是论文《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》中提出者的项目，使用Go语言编写，它比较适用于社区和开发者方面。

• 项目地址：https://github.com/lightningnetwork/lnd
• LND Developer Site： https://dev.lightning.community/

开发支持：

• LightningJ - Lightning APIs for Java

风险：目前LND还不支持导出私钥https://github.com/lightningnetwork/lnd/issues/732

eclair

Eclair(法语闪电)是闪电网络的Scala实现。它可以运行GUI，也可以不运行GUI，还可以使用JSON-RPC API。因为是Scala开发的，所以适用于所有的java语言，适合商业场景。

• 项目地址：https://github.com/ACINQ/eclair

c-lightning

用C实现的一个规范兼容的闪电网络。

• 项目地址：https://github.com/ElementsProject/lightning

其他实现

• Raiden Network - Python实现
• lit - Go实现
• lightning-onion - Go实现
• ptarmigan - C实现

其他资料

• Awesome-lightning-network

前置条件

• 已经安装好Docker
• 能够科学上网

构建Bitcoin客户端

从源码构建bitcoin客户端，我们分为以下几步：

• 选择一个Linux，并安装系统依赖库
• 从github下载代码库，并切换最新的版本
• 运行autogen.sh脚本
• 运行configure脚本
• 运行make和make install
• 验证bitcoin安装成功

所以，我们的Dockerfile如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# 基于alpine linux构建
FROM alpine
# 安装安装系统依赖库
RUN apk update && apk add git \ 
                          make \
                          file \
                          autoconf \
                          automake \ 
                          build-base \
                          libtool \
                          db-c++ \
                          db-dev \
                          boost-system \
                          boost-program_options \
                          boost-filesystem \ 
                          boost-dev \ 
                          libressl-dev \ 
                          libevent-dev
# 下载源码，并切换到最新的分支
RUN git clone https://github.com/bitcoin/bitcoin --branch v0.17.0.1 --single-branch
# 运行autogen.sh脚本 以及 运行configure脚本 以及 运行make和make install
RUN (cd bitcoin  && ./autogen.sh && \
                      ./configure --disable-tests \
                      --disable-bench --disable-static  \
                      --without-gui --disable-zmq \ 
                      --with-incompatible-bdb \
                      CFLAGS='-w' CXXFLAGS='-w' && \
                      make -j 4 && \
                      strip src/bitcoind && \
                      strip src/bitcoin-cli && \
                      strip src/bitcoin-tx && \
                      make install )

运行
docker build -f bitcoin.dockerfile -t bitcoin-alpine .构建一个docker镜像。

在成功构建镜像后，通过命令运行镜像docker run -it bitcoin-alpine-bin。

bitcoind 默认的安装位置是/usr/local/bin。你可以通过询问系统下面2个可执行文件的路径，来确认bitcoin是否安装成功。

1
2
3
4
5

/ #  which bitcoind
/usr/local/bin/bitcoind
/ # which bitcoin-cli
/usr/local/bin/bitcoin-cli

然后，在运行的容器中运行bitcoin的后台程序：

bitcoind -server=1 -rest=1 -regtest -txindex=1 -daemon

通过运行bitcoin-cli -regtest getblockchaininfo，bitcoin-cli -regtest getnetworkinfo，bitcoin-cli -regtest getwalletinfo可以获得到相关的状态信息。

其中：

1
2
3

- getblockchaininfo: blocks, difficulty, chain
- getnetworkinfo: version, protocolversion, timeoffset, connections, proxy, relayfee, warnings
- getwalletinfo: balance, keypoololdest, keypoolsize, paytxfee, unlocked_until, walletversion