微服务架构实践 - 你只懂docker与spring boot就够了吗？

微服务并不是单独存在的，为了更好地实现微服务架构，需要整合许多组件混搭使用，方能打通任督二脉，天下无敌。网上很多大拿讲了微服务治理的内容，也有人单方面讲微服务的，比如spring boot与docker，本文着重于组件选型的较量，也积累了我们团队多次PK的精华；这些组件包括spring boot、spring cloud、docker、服务注册发现、RESTFUL、postman、jenkins、ELK、ETCD等。

背景

随着公司一年多的成长，我们已经开发了数十个项目了，后台有JAVA的有PHP的，为了更好地提升开发与管理效率，各技术大牛小牛们时常进行激烈的PK，碰撞出了许许多多爱的火花，比如其中之一：微服务实践

设计

只需要有一套BASE微服务，BASE微服务生成业务系统微服务实例，供各个业务系统调用；业务系统不直接调用BASE，只能调用微服务INSTANCE。

问题一：有些人会问，假如有20个业务系统，那就有上百个微服务，这怎么管理得了？

这是运维的问题，让运维去解决，运维使用工具，实际也不算困难，反正执行的都是脚本，不需要手工操作。

问题二：为什么不做成一个saas的微服务，这样就只有不到10个的微服务，就非常容易管理了不是吗？

单点故障影响全局，我们选择了稳定更重要；另外saas的话，为了应对不同行业，会存在过度设计的嫌疑；私有化更容易。

调用逻辑

客户端调用业务系统，不直接调用微服务；

微服务内部也存在调用关系。

设计理念

1. 模块化是基础

非模块化，谈不上微服务，比如我们上面的用户微服务、产品微服务、地址微服务等，都需要先模块化，为了更好地落实开发，你可能不得不，边模块化边微服务，模块化的时候要注意，不能有关联查询，包要完全独立，到时候微服务才能拆开。

松耦合、强内聚

松耦合表示我们模块之间不直接依赖，无状态，可以单独地为外界提供服务；

强内聚是指，我们虽然要拆分成一个个小的微服务，但是也要考虑某些功能的强关联性，比如一个凳子是由四个脚与一个板组成，我们不能把四个脚与板分开售卖，就没有意义了。

开发

强大而友好的spring体系

java开发5年以上的都非常清楚，很多JAVA框架都淡出了视野，比如hibernate、struts1、struts2，唯有spring越来越受欢迎。

spring-boot:较springmvc更加简约了，springmvc有一大零的配置文件，比如spring-servlet、spring-mybatis、spring.xml与web.xml，这些在spring-boot都不需要了，只需要强大的注解功能即可，boot更合适微服务。

spring-cloud:里面有比较多组件，用于支持微服务，比如spring cloud config统一配置中心，用于多环境的配置文件配置，大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了；spring cloud eureka用于服务注册与发现，下面有单独介绍；其它的组件大家可以去官网看看，这里不一一介绍，总之如果JAVA平台，尽量使用spring体系的内容。

数据库

我们采用mysql，因为我们是应用多，但数据量单表并不算大，多则不超过百万，mongodb也实验过，开发非常快，也非常灵活，但因为不是关系型数据库，维护成本较高。

权限认证

针对外部校验，内部完全信任机制。