BoatHouse微服务架构选型

zhouwenyang commented 4 years ago

BoatHouse采用微服务架构进行开发，通过领域驱动设计(Domain-Driven Design) 的方式来划分业务（目前已有：统计服务、商品服务、账户服务、订单服务、支付服务），每一个业务领域均可以进行独立开发和部署。关于微服务架构选型，我们建议优先选择Sping Cloud+K8s/Istio的方式进行开发和部署，如果大家其他更好的建议或问题，欢迎在下面留言。

下表中Spring Cloud列第一个黑色粗字体的组件为BoatHouse社区推荐组件。

问题领域	SpringCloud	Kubernetes && ISTIO
配置管理	Spring Config Server	ConfigMap & Secret
服务注册发现	Consul、Eureka、ZooKeeper	Kubenetes Service
负载均衡	Spring Cloud LoadBalancer、Ribbon	Service/Ingress实现NLB，云厂商NLB
API网关	Spring Cloud Gateway 、Zuul	Istio Gateway
安全性	Spring Cloud Security	Ambassador支持多种基于Token的认证方式以及第三方认证代理，如：Auth0和Keychoak
故障熔断	resilience4j、Hystrix	Istio
分布式链路追踪	Spring Cloud Sleuth	Kiali
日志分析	ELK Stack	Fluentd+ ELK
集群监控	Micrometer、Turbine	Heapster+ InfluxDB + Grafana
消息总线	Spring Cloud Bus
服务监控	Spring Admin

总体技术选型原则：

优先选择Spring社区活跃度高的项目
不建议基于已进入维护模式的Spring项目（例如Ribbon、Zuul、Hystrix、Turbine）进行开发，尽量选择社区维护性好的组件进行可持续开发

相关资料：

fudaliang commented 4 years ago

技术选型建议： 1、Spring Config Server依赖git，本身引入组件较多。建议用Consul和nacos这种配置中心、注册中心一体的服务。 2、2018年eureka后续版本不再开源，不建议选。受其影响社区提供了spring gateway同步替代zuul。 3、Spring Cloud Bus会依赖mq，明确mq选型，个人建议用kafka 4、建议明确spring cloud套件版本

fudaliang commented 4 years ago

服务安全：应用一般控制两个方面的访问，一个操作权限（如增删改）；一个资源的访问权限。 1、在部署上，设计一个安全区域（虚拟网段/虚拟机房）。安全区域内的服务只能通过api网关访问。 2、网关负责操作权限和资源权限的验证， 3、安全区域内的服务仅验证网关身份，不验证用户鉴权校验，信任网关发了的请求。仅验证返回结果是否合法。 4、账号服务负责管理账户拥有的操作权限和数据权限 5、建议采用jwt或者了类似机制，避免引入一个集中的会话缓存机制。

pipin commented 4 years ago

建议选用Spring Cloud Hoxton的套件版本，对应Spring Boot 2.2.x

idcf-boat-house / boat-house-frontend

BoatHouse微服务架构选型 #173