1、微服务概念
微服务架构是一种架构风格与设计模式，具有如下优点：小而专，提倡将大的应用分割成一系列小的服务；高内聚，每个服务专注于各自单一的业务功能；独立运行，每个服务运行于独立的进程中，有清晰的服务边界；轻量级通讯，采用轻量级的通讯机制（Http/Rest）来实现互通、协作。
小而专，提倡将大的应用分割成一系列小的服务。比如将电商平台一个单体应用拆分成购物、交易、物流、商品，跨功能开发团队（特性团队）负责各自模块从需求、UI、设计、实施、运维全过程，快速交付用户价值。
高内聚，每个服务专注于各自单一的业务功能。交易服务就只聚焦交易相关业务，订单管理和支付管理等。
独立运行，每个服务运行于独立的进程中，有清晰的服务边界。
轻量级通讯，采用轻量级的通讯机制（Http/Rest）来实现互通、协作。应用之间采用这种轻量级的通讯机制，使这些应用可以采用不同的编程语言、数据存储技术等进行开发，将其集中管理程度降到最低。另外RESTful通讯是无状态HTTP协议，扩展能力很强。同时传输内容JSON形式序列化，轻量简单，人与机器均可读，学习成本低。
2、微服务设计
微服务通常将每个功能都分割成一个一个服务，然后在分布式集群中按需进行横向扩展。单体应用将所有功能都放到一个系统中，并且只能通过整体复制的方式进行横向扩展。这是单体应用和微服务模式的一个主要不同点。
微服务化可以借助SpringCloud组件解决单体应用难以解决的问题。例如SpringCloud组件中的zuul网关可以对请求进行鉴权、限流，灰度发布，权限控制、路由、监控等功能；Hystrix可以对服务进行熔断、降级处理。就比如说有一个热点新闻出现了，系统会推荐给用户查看新闻详情，然后用户会通过id去查询新闻，但是因为这条新闻太火，大量用户同时访问可能会导致系统崩溃，那么我们就进行服务降级，部分服务直接提示“当前人数太多请稍后查看”等。
2.1、采用聚合模式的微服务架构
采用聚合模式的微服务架构
聚合模式是使用最广泛的一种设计模式，其中聚合层（聚合服务）绘制界面和接收用户请求，后面的原子服务层（服务A/B/C）处理用户请求，进行具体业务逻辑处理。
这种微服务架构模式，往往会涉及到去中心化数据管理，像数据库表怎么拆分，拆分后数据表怎么关联查询等。这种模式的架构，数据库通常按照业务进行纵向切分，并且遵循一定原则的：
1）避免跨库的事务处理
当然事务不跨库是最好的，但微服务中分布式事务是不可避免的，对分布式事务处理也有比较成熟的解决方案：
两阶段提交，顾名思义两阶段提交就是把事务处理分两个阶段，第一阶段只操作不提交，某个操作失败进行回滚，都操作成功进行第二阶段提交操作。
另外一个成熟的解决方案，事务补偿TCC方案，在这个方案中需要借助事务协调器，业务应用（聚合层服务）在事务协调器中注册一个事务，然后业务应用直接调用各原子服务Try接口，根据返回结果进行提交或回滚操作，各原子服务Try接口均返回成功，向事务协调器提交事务，之后事务协调器完成Confirm接口和Cancel接口的操作，之后的Confirm接口和Cancel接口的操作都由事务协调器完成；Confirm接口和Cancel接口采用事务补偿机制，将之前失败的事务进行反向操作，来对事务进行补偿；采用TCC方案不能保证执行过程中数据一致性，但能保证最终一致性。
2）避免库间的表关联查询
以订单查询/客户查询/供应商查询为例，首先分页查询出订单信息，然后查询客户信息和供应商信息（rest一次获取），最后对订单信息进行补填，这样就可以避免库间的表关联查询；读写分离机制，生产库中进行实时性读写操作，在查询库上进行查询操作，生产库向查询库上同步数据时，把join操作放到查询库的一张表上，从而在查询库上查询可以达到秒级。
3）改变原来的查询方
2.2、采用代理模式的微服务架构
采用代理模式的微服务架构
采用代理模式的微服务架构，可以看做聚合模式的一个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
2.3、完整的微服务架构
完整的微服务架构
上图为聚合模式的比较完整的微服务架构，其中可以清楚看到SpringCloud组件在微服务架构中充当的不同角色。最外层对外提供服务的是服务网关Zuul，提供路由功能、过滤功能、权限验证等功能；最底层为原子服务层，它进行具体业务逻辑处理；聚合层聚合服务，它主要作用是绘制界面和接收用户请求；管理中心包括注册中心Eureka和配置中心Config，或是使用阿里巴巴Nacos。
