什么是微服务架构？ 微服务是系统架构上的一种设计风格； 主旨是将一个原本独立的系统拆分成多个小型服务； 这些小型服务都在各自独立的进程中运行； 服务之间通过基于HTTP的RESTful API进行通信协作。 为什么选择Spring Cloud？ SpringCloud不只是解决微服务的某一个问题，而是一个解决微服务架构实施的综合性解决框架； 整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了一些非常优秀的边缘组件 大量的兼容性测试，保证了更好的稳定性 应用程序访问安全将会面临更多更复杂的挑战，尤其是开发者最关心的三大问题：认证授权、可用性、可视化,本项目主要从这三个角度去解决这些问题

构建大并发、高性能、高可用系统中几种通用的优化思路，并抽象总结为“4 要 1 不要”原则，也就是：数据要尽量少、请求数要尽量少、路径要尽量短、依赖要尽量少，以及不要有单点。项目主要从技术角度上看“稳、准、快”，就对应了我们架构上的高可用、一致性和高性能的要求 高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。本专栏将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这 4 个方面重点介绍。 一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，我将用一篇文章来专门讲解如何设计秒杀减库存方案。 高可用。 虽然我介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，我们还要设计一个 PlanB 来兜底，以便在最坏情况发生时仍然能够从容应对。

RPC，远程过程调用，可以做到像本地调用一样调用远程服务，是一种进程间的通信方式 RPC框架需要重点关注哪几个点： 代理 （动态代理） 通讯协议 序列化 网络传输 1. Protocol（协议） 首先我们需要确定通信双方的协议格式，请求对象和响应对象 请求对象： @Data @ToString public class RpcRequest { /** * 请求对象的ID */ private String requestId; /** * 类名 */ private String className; /** * 方法名 */ private String methodName; /** * 参数类型 */ private Class[] parameterTypes; /** * 入参 */ private Object[] parameters; } 请求对象的ID是客户端用来验证服务器请求和响应是否匹配 响应对象： @Data public class RpcResponse { /** * 响应ID */ private String requestId; /** * 错误信息 */ private String error; /** * 返回的结果 */ private Object result; } 2. 序列化 市面上序列化协议很多，比如jdk自带的，Google的protobuf，kyro、Hessian等，只要不选择jdk自带的序列化方法，（因为其性能太差，序列化后产生的码流太大），其他方式其实都可以，这里为了方便起见，选用JSON作为序列化协议，使用fastjson作为JSON框架 具体详情可查看项目