架构基础演变，初识Springboot，讲解Springboot的简单demo及restful风格

讲解架构演变是为了引入微服务的概念，引入微服务是为了理解springboot能干些什么，最后写一个简单的spring的demo，稍微引申下restful风格

架构演变：

案例：零几年的时候，海哥发现实体超市众多，但是网上超市是一片蓝海，所以开始搞网上超市

初期：

但是随着时间推移，各个超市争相效仿，所以海哥决定针对不同场景要弄营销策略

业务发展：
原基础架构上扩展功能

这一阶段存在很多不合理的地方：

网站和移动端应用有很多相同业务逻辑的重复代码。
数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱。
单个应用为了给其他应用提供接口，渐渐地越改越大，包含了很多本来就不属于它的逻辑。应用边界模糊，功能归属混乱。
管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用。
数据库表结构被多个应用依赖，无法重构和优化。
所有应用都在一个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。
开发、测试、部署、维护愈发困难。即使只改动一个小功能，也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代码，或者修改了一个功能后，另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响，所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行，还得盯到第二天白天的用户高峰期……
团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久，最后要么干脆各做各的，或者随便放个地方但是都不维护。
尽管有着诸多问题，但也不能否认这一阶段的成果：快速地根据业务变化建设了系统。不过紧迫且繁重的任务容易使人陷入局部、短浅的思维方式，从而做出妥协式的决策。在这种架构中，每个人都只关注在自己的一亩三分地，缺乏全局的、长远的设计。长此以往，系统建设将会越来越困难，甚至陷入不断推翻、重建的循环。

转变：
将功能抽象出来，将各个服务分开，数据库还是公用的

缺点：

数据库成为性能瓶颈，并且有单点故障的风险。
数据管理趋向混乱。即使一开始有良好的模块化设计，随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象。
数据库表结构可能被多个服务依赖，牵一发而动全身，很难调整。（耦合度高）
再次转变：

优点：分工明确，责任清晰

缺点：

先举个案例：如果上线后，某时段，促销服务挂了，和之前比，定位困难（需要挨个服务拉日志），手动调用接口，来定位问题

微服务架构整个应用分散成多个服务，定位故障点非常困难。
稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。（雪崩效应）
服务数量非常多，部署、管理的工作量很大。
开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂
解决问题：
1.监控-发现故障的征兆

2.定位问题-链路跟踪

实现：每次服务调用会在http的headers中记录至少四项数据：

traceId：traceId标识一个用户请求的调用链路。具有相同traceId的调用属于同一条链路。
spanId：标识一次服务调用的ID，即链路跟踪的节点ID。
parentId：父节点的spanId。
requestTime & responseTime：请求时间和响应时间。
增加拦截器，给每个http请求塞上数据，并异步的发送日志（这次Springboot里不讲拦截器，拦截器，过滤器，aop等等，有机会再讲，如果想要demo，可以找我要）

3.分析问题-日志分析

日志分析组件：ELK（这个我不会，就普及下概念，但是咱们用过，就是ES系统）

Elasticsearch：搜索引擎，同时也是日志的存储。
Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch。
Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户。
4.网关-权限控制，服务治理

5.服务注册于发现-动态扩容

6.熔断，服务降级，限流

（4，5，6有兴趣的可以研究下，这里不做扩展了）

Springboot
说了那么多，到springboot了

SpringBoot能干什么？为什么用它？
随着动态语言的流行（Ruby、Groovy、Scala、Node.js），Java的开发显得格外的笨重，繁多的配置、低下的开发效率、复杂的部署流程以及第三方技术集成难度大。

在上述环境下，SpringBoot应运而生。它使用“习惯优于配置”（项目中存在大量的配置，此外还内置一个习惯性的配置，让你无须手动进行配置）的理念让你的项目快速运行起来。

使用SpringBoot很容易创建一个独立运行（运行jar，内嵌Servlet容器）、准生产级别的基于Spring框架的项目，使用SpringBoot你可以不用或者只需要很少的Spring配置。

SpringBoot优缺点
1）优点

快速构建项目。
对主流开发框架的无配置集成。
项目可独立运行，无须外部依赖Servlet容器。
提供运行时的应用监控。
极大地提高了开发、部署效率。
与云计算的天然集成。
2）缺点

版本迭代速度很快，一些模块改动很大。
由于不用自己做配置，报错时很难定位。
网上现成的解决方案比较少。
IOC和DI
IOC-控制反转，DI依赖注入

Demo
前提条件：本地数据库course里有个tb_user的表。
最终目的：通过springboot把表里内容读出来，并在浏览器上展示
代码地址：
https://gitee.com/feng_chong/fengchong-study/tree/master/