微服务核心技术梳理
学习本文前，请确保你了解并搭建过至少一个简单的微服务应用。对微服务的设计理念及编程思想有一定的了解。
当我们需要自己从零开始设计或搭建微服务项目的时候，由于缺乏经验及高人指点，心中难免有些惶恐。我们要如何去搭建我们的微服务项目？如果不能一步到位的话，我们该如何逐步去实施？微服务系统会存在哪些常见问题？有哪些风险点需要去关注？微服务的边界在哪里，哪些东西可以用微服务来实现，哪些不能？
那么本文讲从易到难、从浅到深、逐步实现从实用到四高的相关技术梳理(高可能、高性能、高并发、高智能)。让你在微服务项目的各个阶段都能够不慌不忙，胸有成竹的构建及完善我们的微服务项目
1.微服务最少组件
当我们对微服务的四高没什么要求的时候，仅仅是想将项目拆分成多个团队并行开发，那我们要如何去搭建我们的微服务项目呢?
以dubbo微服务框架为例:
我们至少需要有api网关、zk、provider、consumer
2.微服务编排
当我们对微服务项目进行拆分的时候，该如何下手，怎么拆分才是正确的? 有没有统一的标准？
目前业内对微服务的拆分并没有统一的规范及标准，拆分的时候必须根据具体的业务及开发团队现状来确定。下面我们以一个旅游微服务系统平台实例来进行说明：
RPC依赖关系图
从上图我们不难看出一些基本的编排规则：
- 微服务不能交叉调用，否则上线的时候可能会出现服务不可用的问题
- 微服务可以是独立的、不依赖其他任何服务的
- 微服务必须进行分层，低层级的不能调用高层级的微服务
- 微服务的交互方式，必须提前设计好，是同步还是异步？
比如: 消息通知最好用MQ异步来实现，否则会影响诸如订单主流程的运行
3.微服务排障
当我们在线运行的微服务项目频繁出现Bug，又无法快速准确的定位的时候，我们需要对微服务项目进行哪些升级改造？
以Dubbo微服务框架为例，常见的使用zipkin来进行调用链的跟踪：
zipkin
在zipkin的图形管理界面上，很容易能看到调用链故障环境
ELK日志系统通过对日志的监控及分析，也可以帮我们快速定位故障
ELK日志监控界面
4.微服务的高并发
当微服务项目在线运营一段时间后，总会迎来流量的高峰，那我们应该提前做好哪些准备来应对高并发的用户场景呢？
- 利用Nginx进行前后端分离，请静态资源部署在NG上
- 接入云存储，把图片、视频、app安装包等发布到云存储上
- 把云存储、静态资源全部接入CDN，并做好相应的策略
- 充分利用Redis等缓存层，减轻数据库的压力
5.微服务高可用
当个别微服务偶尔出现问题影响用户体验的时候，比如偶尔用户无法下单、无法支付，又或者我们需要频繁升级的时候，我们应该采取什么样的措施？
- 负载比较高的服务，相同的开启多个
- 上线发布的时候，采用灰度发布的方式
- 打开错误重试机制，dubo默认重试3次
6.微服务的高性能
当一个项目用户越来越多、业务越来越复杂、我们该如何保证在复杂的业务场景下，实现对用户请求的快速响应？
- 数据库开启一主多从，把查询量大的微服务单独分配到从库上
- 利用Mycat等服务中间件，实现对数据库主从自动切换
- 利用MapReduce算法，都任务进行分片处理，统一结果汇总
- 利用多库进行数据库水平拆分，也就是我们常说的分库分表
- 把查询量大的服务采用NoSQL数据库(例如：ES)进行部署
7.微服务的分布式事务
当多个微服务同时处理一个用户请求的时候，比如用户下单需要同时调用权限系统、商品管理系统、进销存系统、支付系统等微服务，如果保证数据的一致性？而且失败的时候还必须同时回滚？
常见的分布式事务有2种
- 补偿机制，利用定时任务检查数据是否需要回滚
- 强事务，利用mysql的xa事务(也可以使用各种中间件：比如阿里的FESCAR)
#mysql实现XA事务的SQL语句
XA START 'xatestx','XXXXXXXXXXXXXXXXXXXXXXXX';
INSERT INTO suoron_test (id,name) VALUES(21,'试试');
XA END 'xatestx';
XA PREPARE 'xatestx';
#大家都准备好了，一块提交
XA COMMIT 'xatestx';
XA ROLLBACK 'xatestx';
XA RECOVER;
8.微服务服务治理
当我们团队越来越大的时候，我们需要把系统交付给运维的兄弟进行维护，我们该如何帮忙他们制定专门的运维管理的规则？
微服务治理
常见的服务治理框架有：
- Dubbo的Admin -- 服务管理
- Spring cloud 的hystrix -- 熔断
- zabbix -- 微服务监控及巡检
- apollo -- 携程配置管理(后期服务器配置全由运维负责)
9.微服务的高智能
当系统出现问题，或者资源不够的时候，每次需要手工去维护显然不现实，人工处理的响应速度太慢，恢复一个故障可能需要长达几个小时的时间，那我们该如何实行系统的智能运行？
必须充分利用容器集群及容器调度系统（例如：Kubernetes）
比如：微服务出现严重故障时，容器能够自动重启
当请求流量增大的时候自动开启新的微服务
当流量减少时，自动释放资源，用于资源消耗严重的报表统计等
