Java微服务架构

传统的整体式架构 传统的整体式架构都是模块化的设计逻辑，如展示（Views）、应用程序逻辑（Controller）、业务逻辑（Service）和数据访问对象（Dao），程序在编写完成后被打包部署为一个具体的应用。如图所示： 系统的水平扩展 如果要对系统进行水平扩展，通常情况下，只需要增加服务器的数量，并将打包好的应用拷贝到不同的服务器，然后通过负载均衡器（Nginx）就可以轻松实现应用的水平扩展。 整体式架构的缺点 应用复杂度增加，更新、维护困难。 易造成系统资源浪费。 影响开发效率。 应用可靠性低。 不利于技术更新。 面向服务的架构SOA（Service-Oriented Architecture） SOA的思路是把应用中相近的功能聚合在一起，以服务的形式提供出去。如图所示：

缺点 虽然SOA解决了整体式架构中的问题，但多数情况下，SOA中相互独立的服务仍然会部署在同一个运行环境中。和整体式架构类似，随着业务功能的增多，SOA的服务会变得越来越复杂。本质上看，整体式架构的问题并没有因为使用SOA而变得更好。

微服务架构 微服务架构是一种架构风格和架构思想，它倡导我们在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，可以独立承担对外服务的职责，通过此种思想方式所开发的软件服务实体就是“微服务”，而围绕着微服务思想构建的一系列结构（包括开发、测试、部署等），我们可以将它称之为“微服务架构”。如图所示：

缺点 开发人员必须处理创建分布式系统的复杂性。 部署的复杂性。 增加内存消耗。 微服务架构与SOA的区别

如何构建微服务架构 微服务架构的组件 （1）服务注册中心：注册系统中所有服务的地方。 （2）服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。 （3）服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址。 （4）负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。 （5）服务容错：通过断路器（也称熔断器）等一系列的服务保护机制，保证服务调用者在调用异常服务时能快速地返回结果，避免大量的同步等待。 （6）服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。 （7）分布式配置中心：将本地化的配置信息（properties、yml、yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。 微服务架构的技术选型 （1）微服务实例的开发：SpringBoot （2）服务的注册与发现：Spring Cloud Eureka （3）负载均衡：Spring Cloud Ribbon （4）服务容错：Spring Cloud Hystrix （5）API网关：Spring Cloud Zuul （6）分布式配置中心：Spring Cloud Config （7）调试：Swagger （8）部署：Docker （9）持续集成：Jenkins