最近做项目，是在已有数据库基础上写业务，然后发现了很多本是外键的字段并没有设置外键约束。因为之前都是按照规范建数据表，所以对此有点奇怪，然后在网上找到了比较好的回答。
大家共同观点：主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省了其它的工作。
矛盾焦点：数据库设计是否需要外键。这里有两个问题：如何保证数据库数据的完整性和一致性；在第一条的基础上对性能的影响。
上一章使用了配置中心服务器和客户端，使得配置可以统一。
当服务实例很多时，都要从配置中心读取文件，这时就可以考虑将配置中心做成一个微服务，将其集群化，从而达到高可用的目的。不需要我们为这些 Config 服务端做任何额外的配置，只需要遵守一个配置规则：将所有的 Config Server 都指向同一个 Git 仓库，这样所有的配置内容就通过统一的共享文件系统来维护，而 Config Client 客户端在指定 Config Server 位置时，只要配置 Config Server 外的均衡负载即可。
上一章使用了路由网关进行路由转发和安全验证，这章将搭建分布式的配置中心。
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在 SpringCloud 中，有分布式配置中心组件 SpringCloud Config，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在 SpringCloud Config 组件中，分两个角色：Config Server 和 Config Client。
SpringCloud Config 为服务端和客户端提供了分布式系统的外部化配置支持。配置服务器为各应用的所有环境提供了一个中心化的外部配置。它实现了对服务端和客户端对 Spring Environment 和 PropertySource 抽象的映射，所以它除了适用于 Spring 构建的应用程序，也可以在任何其他语言运行的应用程序中使用。作为一个应用可以通过部署管道来进行测试或者投入生产，我们可以分别为这些环境创建配置，并且在需要迁移环境的时候获取对应环境的配置来运行。
上一章搭建了基本的服务架构，这章将了解断路器。
在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，最终导致自身服务的瘫痪。
举个栗子：
在电商网站中，我们可能会将系统拆分成用户、订单、库存、积分、评论等一系列的服务单元。
用户在调用订单服务创建订单的时候，会向库存服务请求出货（判断是否有足够库存来出货）。如果此时库存服务因网络原因无法被访问到，将会导致创建订单服务的线程进入等待库存申请服务的响应，在漫长的等待之后用户会因为请求库存失败而得到创建订单失败的结果。在高并发情况下，这些等待线程在等待库存服务的响应而未能释放，会使得后续到来的创建订单请求被阻塞，最终导致订单服务也不可用。
因此相较传统架构，微服务的架构就显得不稳定。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。为了解决这样的问题，就产生了断路器模式。
上一章了解断路器，这章将看看路由网关。
在微服务架构中，需要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，由这几个基础组件相互协作，共同组建了一个简单的微服务系统。
在 SpringCloud 微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（Zuul、Ngnix），再到达服务网关（Zuul集群），然后再到具体的服务。服务统一注册到高可用的服务注册中心集群，服务的所有的配置文件由配置服务管理，配置服务的配置文件放在Git仓库，方便开发人员随时改配置。
项目需要部署到线上，原来都是直接 java -jar 这样运行的，后来才发现服务器的 CPU 占满了，不得不说第一次部署 Java 这么困难。打算用 Tomcat，但是一直启动不了，各种奇怪的原因，无奈换成 Jetty。