前言
微服务已经是比较成熟和广泛的架构及业务解耦的趋势，但是对于航司，尤其是电商领域，其并不是像这个技术那样简单和成熟。需要的是大量的规范化和业务解耦及分析，以及DDD的深入应用。不仅仅为新的电商架构打好基础，更多的是为了后续电商数字化能力的提升，例如OpenAPIs等的实现，播下希望的种子。
如下就对于除了DDD之外的技术层面，尤其架构领域，做一个粗狂的分享。
建设蓝图
1）“实时”/ Real-Time微服务标准化体系
目标如下：
a) 建设基于J2EE基础和Spring Cloud的微服务标准框架及体系。
b) 使用Swagger提高服务自描述能力及服务接口标准化使用。
c) 建设及改造基于IATA的NDC数据规范的微服务服务实例。
d) 建设基于Docker的微服务多版本多环境的自动发布及水平延展容器化结构。
建设内容：
Ø服务自注册及发现的服务注册及管理中心。
Ø服务客户端负载均衡的边缘计算架构。
Ø基于SCM的服务代码的多环境发布及集中管理配置中心。
Ø服务熔断和服务调用链路跟踪的服务跟踪管理中心。
Ø服务API网关和服务注册中心的服务调用统一管理中心。
Ø容器化统一管理平台及微服务自动发布平台。
Ø服务标准化数据Schema，业务数据模型，代码框架
2）“全时”/ Full-Time服务健康及管控全景视图
建设微服务运行状况监控及运维使用平台。
基于Spring Cloud及ELK等第三方框架，和客制化开发实现异常告警，追踪，错误信息汇聚及查询。
运维自动化及AB测试支持。
服务运行状况全时掌握。
服务异常实时告警及追踪定位。
服务故障分析数据汇聚。
自动化服务发布，流控，AB测试支持。
业务功能诉求
a) 服务注册及发现：服务自发现自注册的机制，并提供可视化服务注册及发现中心，方便后续排查，梳理，及管理服务使用。
b) 服务调用网关：在服务消费端，尤其是外部消费者使用服务的时候，通过注册及发现中心获取服务信息后，经由统一的服务网关进行接入，其负责安全校验，负载均衡，服务与应用隔离，以及关键的服务消费校验，避免非法的服务使用。
c) 服务客户端负载均衡：通过边缘计算等概念，在整个服务集群内部的链路调用，消费端使用客户端负载均衡，从而避免内部大量反向代理和负载均衡硬件服务器的使用。
d) 服务标准化开发：服务契约，项目架构及继承，开发规范等标准化。
e) 服务客户端熔断处理：对于服务调用链路的下游服务的调用失败，譬如超时，服务不可用，系统异常等，避免蝴蝶效应的服务全局瘫痪。
f) 服务调用链路跟踪：对于服务集群内部纷繁错杂的服务调用关系，以服务调用链路的方式，从日志和框架的基础上，可视化的跟踪和梳理。
g) 服务配置集中管理：对于服务通用型配置参数，以及多环境多版本的不同配置，集中管理，集中分发，集中使用，避免配置的混淆使用及分散管理。
h) 服务配置分布式协同：对于实时服务配置及参数的变化，在服务集群内部异步方式准实时同步和协同。
逻辑架构
Spring Cloud是技术框架，但是在管理和运维上，缺失很多。逻辑上，为了更好的运营微服务架构，关键是运维及管理。原生的框架基本不具备实际使用及管理能力，同时对于运维也没有太大的支持，只能借助外力，在后续运维及管理上设计及开发相应的功能。
应用架构
UDDI：服务注册及发现中心，即服务黄页。
健康监控：服务日常心跳等运行参数及监控状况指标，和度量信息。
链路跟踪：调用链路的跟踪及展示。
断路监控：特定调用异常的断路处理和监控展示。
异常告警监控：自定义的异常告警监控展示。
故障排查：可视化全局异常及故障排查。
实现架构
其中JHipster将作为关键的实现部件，为服务注册、API网关等提供支撑，同时增强的健康监控将是重点。
Zipkin也是其中对于调用链路的支撑框架，并将ELK作为核心数据持久化的基础。
ElastAlert作为基于ELK的监控全新实现方案。
ELK是整套体系的数据基础。
并客制化一整套监控运维管理的UI及可视化工具箱。
技术架构
以Spring Cloud为核心，辅以经验框架-JHipster构建一套完整的技术架构及管理和运维平台。
JHipster架构
a) JHipster将提供基于Spring Boot及Cloud，和Config及Stream的全套注册中心、网关中心的实现，即Eureka、Zuul、Config的封装及增强。
b) 同时对于Feign等也已经融合进入其体系。
c) 对于安全的增强实现UAA，保障更全面的服务安全管控。
d) 在GitLib之上，结合Spring Cloud Stream实现全局的分布式配置。
e) 并基于AngularJS提供上述全面的可视化实现及展示。
开发经验的汇聚 - Microservices建设的一般诉求：
a) 一个基于Zuul的网关
b) 使用Swagger的整套开发者文档门户
c) 监控及报告
d) API生命周期的自动发布、升级等方案
Spring Cloud架构
全部核心微服务的实现及技术特点，均全部选型自Spring Cloud和相关Spring Boot的框架，无Dubbo等微服务框架使用。
同时注册中心将采用通用Netflix的Eureka等的技术体系，而非Consul技术体系。
UDDI、API Gateway、Load Balancer、Configuration、Logging、Tracing。
JDK 1.8
CentOS 7.x
Spring Cloud & Boot
GitLab CLI / Jenkins
Apache Maven
Nexus RM
Eclipse/STS
ELK
JHipster
Nginx
Swagger
RabbitMQ / Kafka
逻辑拓扑架构
注：这是一个最简的部署模式。
物理拓扑架构
注：这是一个最简的部署模式。
延展生态架构
微服务不仅仅是架构，或者代替SOA发展的架构理念，更关键是企业核心数字资产的重组，并为后续OpenAPIs等的发展提供基础。
Spring Cloud技术堆栈
Spring Cloud是一个优秀的技术框架，但是对于运维、规范性融入、管理等，确实存在缺失：
a) 可视化界面友好性及大规模使用不足。
b) 缺少集中的可视化监控界面。
c) 没有与Swagger充分集成。
d) 熔断等可视化界面使用不便。
e) 没有集中的日志收集和应用。
f) 没有与第三方的监控及运维框架集成。
JHipster微服务架构经验框架
JHipster Registry：Eureka、Zuul和集中可视化监控及配置的集成Angular应用。
Microservices：JHipster生成的应用。
API Gateway：JHipster生产的Angular应用。
JHipster Console：基于ELK和Zipkin的监控及告警平台。
Traefik：负载均衡及反向代理
Consul：JHipster Registry的替代方案
JHipster UAA：支持OAuth2的用户认证授权服务
JHipster服务端核心技术堆栈
JHipster应用案例
如下是一个最简的应用案例和架构布局。
JHipster广泛用户
Eureka & Consul & JHipster Registry
a) Spring Cloud Eureka是Spring Cloud Netflix OSS项目下的服务治理模块
b) Spring Cloud Consul项目是针对Consul的服务治理实现
Spring Cloud Config & Bus、GitLab
使用JHipster框架的体系，基本还是沿用之前Spring Cloud Config的技术体系。
JHipster Registry
其包含如下：Eureka server，Spring Cloud Config server，Administration server (metrics、health、configuration、logs dashboard)
JHipster-Generated API Gateway
其是增强的Zuul实现。
JHipster Console
基于ELK和Zipkin的融合及完整实现体系。
Zipkin链路跟踪架构
a) Spring Cloud Sleuth中对Zipkin的整合进行了自动化配置的封装
b) JHipster也通过Spring Cloud Sleuth集成了Zipkin，且提供在JHipster Console和Kibana的集成界面
c) 由于原生JHipster的支持，将继续沿用Zipkin作为核心链路跟踪的框架。
d) 同于对于Pinpoint等分析之后，Zipkin有强大的技术支持和长远发展，尤其能够得到Spring Cloud社群的支持，故继续沿用Zipkin。
e) 同时对于数据的最终落地，将使用ELK作为数据持久化的存储。
f) 对于后续的查询，将使用Zipkin API的方式，避免二次开发Elasticsearch的查询封装。
Spring Cloud原生断路监控（Hystrix）
Spring Cloud原生的断路确实提供强大的功能，但是不能持久化，并且对于实际运维支持不足。
JHipster Console替代Spring Cloud Hystrix
a) Spring Cloud Hystrix是驻留在内存中的、且基于JMX的Metrics“实时”输出。即数据是On-Demand的、不能持久化、不能后续分析。
b) JHipster的Metrics的收集方式阻塞了Spring Cloud Hystrix的实现。
c) 但是其将全部信息异步的发布并集中到ELK中，结合JHipster Console历史及实时监控，和JHipster Registry上的JMX的Metrics仪表盘，可以更全面的掌握服务断路情况。
Spring Boot & AOP
AOP是全部的关键，将FR实现与NFR实现有机的分割，并且对于框架和具体技术实现进行分割。
请求及响应截获
Swagger UI集中统一暴露
a) 代替各个Microservice项目配置和注册Swagger契约描述
b) 且提供统一的Swagger UI访问地址
Swagger Codegen (API-First)
其不是全新的，其是经验和规范性的服务和敏捷开发模式。而且是后续推广OpenAPIs的关键。
易用性：JHipster Codegen
JHipster的强大不仅仅是经验框架，更关键的是Codegen，用于经验框架代码的生成。
高可用：GitLab HA
对于其中的单点，GitLab，按照如下，进行高可用的部署及调整。
高可用： Zipkin HA
Zipkin是单点，所以必须通过前置的分部署节点进行高可用的支持。例如Kafka的使用。
易用性：基于ElasticSearch的ElastAlert
完全不同于原来Logstash的配置和流转，采用基于ES数据库的监控和配置-ElastAlert实现。
扩展性：Metrics接入第三方石墨
JHipster框架的另外一个强势，就是已经将第三方监控平台，例如石墨，的接入已经实现。
扩展性： Metrics接入第三方普罗米修斯
普罗米修斯是另外一个第三方的JHipster支持。
易用性：Swagger2Markup
JHipster也把文档化的组件集成在其中。
易用性：服务调用链路排查
为了后续使用灵活，客制化开发如下链路排查的UI。
易用性：服务调用地图
对于服务调用地图，也需要额外客制化UI。
