本来想的标题是 《springcloud 和 kubernetes 比较 》
不过想着想着就放弃了，因为本来的出发点就是，有了kubernetes我为啥还要用springcloud ... 想了半天，完全没理由啊
就好像机箱为啥买太阳神，就为了ROG全家桶？没理由啊
第一次用springcloud 还是在 2017年，那时候微服务概念刚刚兴起 （ 也可能是孤陋寡闻的我刚刚听说 ），于是做了一个基于 Docker 的 springcloud 架构
原理就是 Docker 封装的 Springboot应用 然后构成了一个 springcloud 平台，反正当时kubernetes还不熟
不过时至今日，我真心想不出如果重新为一个新项目做技术选型，我为啥还要用springcloud
微服务架构，主要组成有，简单列一些
上一个例子中使用的是 Parameters
这里尝试一下 request body
抛开 go-swagger不谈，直接使用 swagger 应该是下面的样子
openapi: 3.0.0
info:
description: |
This is a sample Petstore server. You can find
out more about Swagger at
go-swagger 会自动查找程序 main 函数入口
然后生成对应的 swagger 文档
也就是说，endpoint 入口是可以，也应该被分开写在不同文件内的
main.go
// Package Helloworld API.
//
// The purpose of this service is to provide an application
// that is using plain go code to define an API
这里有一个复杂的例子
/ Package Helloworld API.
//
// The purpose of this service is to provide an application
// that is using plain go code to define an API
//
启动Swagger的本地服务器最简单的办法就是 docker
docker pull swaggerapi/swagger-editor
docker run --rm -p 80:8080 swaggerapi/swagger-editor
因为实在不喜欢 Java ， 这里用 golang 做一个例子
swagger文档的 info 信息，写在package 之前
// Package Helloworld API.
//
OpenAPI ( OAS ) 是一个语言无关的 RESTful API 接口规范，
OAS 使用几种已知的 format 格式来详细定义所使用的 type 数据类型。
OpenAPI的 根对象
最近这一年里, 我谈论了太多devops, 就像几年前我们谈论了太多敏捷
DevOps 这儿... DevOps 那儿... but what is exactly DevOps is ...
如果你打开百度, 搜索关键字 DevOps 你会得到
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
但是, 我们真的需要说得这样 概念化么? 它到底是什么, 它又如何在项目中落地, 它的核心思想到底是什么呢, 这几天这个问题一直在困扰我.
早在2010年, 当时我还是一个只有2年半工作经验的Junior developer, 我们有差不多130个人工作在一个网银系统项目中, banking 系统, 信用卡系统, 登录系统, core系统, 基于SOAP的webservice接口系统... 所有这些都必需编译并且集成到一起
从4月份开始着手搭建这套环境已经有半年了，幸亏我有两只手，要不还真不够用
one hand 。。。the other hand 。。。
跟我一开始想的一样，hybris 这种安装完成 就变成几个G 大小的
传统java 应用确实不太适合在 容器编排工具上使用，不是说它不能用，而是，它完全享受不到容器化的好处。
首先，现在的结构里我们可以把hybris拆分成3个镜像（当然每个镜像还是很大）
hybris、solr、mysql 都可以独立成为镜像，
solr 和 mysql 本身都可以做成集群的，分布式也很容易，
mysql 分布式太麻烦或者吞吐量不够的话你还可以花钱解决问题，选择一些和 mysql 兼容的云数据库比如 RDS 什么的，同时也可以解决 数据安全和备份的问题。
但是 hybris，理想状态下，sap一直宣称 hybris 是基于 模块的，addon 什么的，说它易于扩展，方便二次开发，可复用
但是实际上，每个 OOTB 原生功能的addon都不能独立以微服务的方式运行，甚至如果你基于addon的模式进行开发，你的自定义addon也无法以微服务的形式运行。
如果你还记得12306网站那个著名的 "系统太忙请稍后再试"你一定遇到过限流
或者是jd的抢购活动的"服务器太忙请稍后再试" 都是限流的结果
限流的好处在于防止非预期的请求对系统压力过大而引起的系统崩溃
一般Web系统的访问限制都可以用容器本身来实现，比如tomcat就可以在connector上面配置connection数目的限制，servlet thread限制
不过如果不同的URL需要配置不同的限制, tomcat显然是做不到的
这个时候就需要实现自己的限制
常用的限流算法有两种 漏桶算法和令牌桶算法
漏桶算法
请求会先进入一个漏桶里, 假设漏桶每分钟滴4滴水, 那么就有4个请求在这一分钟里被处理,如果水桶满了, 就意味着可以goto error page 了
这个问题其实还是Brian问的, 他真的去做那个 "拍卖系统" 了
这个拍卖系统有一个需求是 " 假设用户设定的拍卖开始时间是2017年1月1日中午12点, 那么系统需要在拍卖会开始之前半个小时给参与的bidder们发送提醒邮件"
这个功能看起来貌似很简单, 不过仔细想起来以前好像还真没碰到类似的
1. 发送邮件的job触发一次之后, 就会被移除 ( 不像springbatch或者crontab那种定时器触发, 要触发好多次)
2. job的数量不固定, 以前做的job都是程序员设定的, 不会由用户创建, 所以如果job数量特别大,可能会出问题
3. job的触发时间是用户设定的, 如果同一时间有大量job需要触发, 而且如果邮件发送特别慢的话,也可能会出问题
下面给出两个解决方案
总的来说各有利弊, 下面请看详细
第一种, 使用atd服务实现
安装atd服务
yum -y install at