微服务（一）

    一个工程对应一个归档包(war)，这个war包 包含了该工程的所有功能。我们成为这种应用为单体应用，也就是我们常说的单体架构。具体描述: 就是在我们的一个war包种，聚集了各种功能以及资源，比如JSP,JS,CSS等。

（假设每个服务器只能抗住200用户，怎么才能让两台服务器起到均衡分配的作用？） 采用Nginx负载均衡，使得每台服务器都能平均分压。

4.1 什么是分布式session的问题？     网站是需要登陆的，登录的信息是保存在服务端，浏览器服务端请求是http请求，而http请求是短链接，无状态的，这意味着这次请求和下次请求是没有关系的，如果有session id的话，会将其保存在服务端，用来进行通讯。所以当使用分布式后，请求的服务器和响应的服务器可能不是同一个，这就会导致分布式的session不同步。 4.2 分布式session解决方案

方案一：Session Sticky（不适用于流量大应用）     利用负载均衡的策略，根据ip进行hash，将一个ip的所有session数据都存在一个tomcat上。能解决分布式session的问题，但是会存在局部的单点故障问题（当一个服务器挂掉，就拿不到数据了） 方案二：Session Relication（不适用于流量大方案应用）     该方案是一个session复制的方案，多个服务器的数据进行同步。能解决分布式session的问题和单点故障的问题，但有一个很大的弊端，非常的耗内存，耗宽带，每一个tomcat都会保存所有的session数据，当tomcat服务器多了，每更新一天数据都要相互同步通知，非常耗宽带。 方案三：Session Center     需要增加额外的技术：Redis。该方案能解决方案一和方案二的问题，但是也有一个问题，需要增加Redis，Redis数据库也需要维护和高可用，对此要求特别高（全世界使用redis最多的公司是：新浪）。

随着流量的继续增加，最暴力的措施就是直接增加服务器。

直接增加服务器可以解决应用程序的吞吐量和并发，但会遇到一个新的问题：数据库受得了吗？

解决方案：

主从同步底层原理：

读写分离的两种解决方案：

proxy代理的方法（代理层）：是指使用atlas代理实现方法增强(360开源的框架)，根据不同情况，插入数据选择master数据库，查询数据选择slave数据库。判断是再proxy代理层进行的。 jdbc增强的方法（应用层）：使用jar包拦截jdbc协议，再根据sql进行逻辑判断选择不同数据库。

两种方法对比： proxy性能差一点，扩展性强，支持跨语言，大多数会用这种方案；jdbc增强性能好，但是具有局限性，不支持跨语言。

应用：如果在slave从数据库中修改数据，数据可能不会同步到master主数据库，但是如果使用主数据库代理后去查数据，查到的应该是被修改过的从数据库的数据，而不是未修改的主数据库数据，这就说明实现了读写分离。

主从同步的弊端（面试必考）：当商品下单成功时，数据插入到了master数据库里，但是在同步binlog的过程中出现了故障，导致数据没有及时同步，就会出现问题。 解决方案：强制路由（注释的逻辑） 在执行语句前面加注解的方式

第一条语句走的是查询slave数据库，第二条语句强制路由，走的是master数据库。

垂直分库

水平分库

微服务的定义:http://blog.cuicc.com/blog/2015/07/22/microservices 微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务，可以理解为是去中心化的一个逻辑。

①: 比如传统的单机电商应用, 商城里面有订单/支付/库存/物流/积分等模块(理解为servcie) ②:我们根据 业务模型来拆分,可以拆分为 订单服务，支付服务，库存服务，物流服务，积分服务 ③若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整个服务宕机.若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用。

A：合适 ①:大型复杂的项目 ②:快速迭代的项目 ③:并发高的项目 B：不合适 ①：业务稳定，就是修修bug ，改改数据 ②：迭代周期长 发版频率 一二个月一次.