Note	Master分支正在构建如下功能： 升级到 Spring Boot 2.x 全面容器化，以K8s为容器平台，兼容Spring Cloud与Service Mesh两类微服务体系 支撑中间件优先使用CNCF下的产品，如使用 jaeger 代替 zipkin 如需要存粹的Spring Cloud扩展请切换到 1.5.1-RC tag.

Dew微服务体系

微服务一站式解决方案，提供：架构指南、容器优先/兼容Spring Cloud与Istio的框架、最佳实践及Devops标准化流程。

Dew [du:] 意为`露水`，希望此体系可以像晨间的露水一样透明、静谧、丰盈。让使用者尽量不要感知Dew的存在，专注业务实现。

设计理念

微服务架构的尴尬

几乎人人都在谈微服务，每个IT企业都在做微服务架构，但大部分项目都会存在这样的尴尬：

• 什么是微服务？怎么做微服务架构？为什么这么乱？

缺乏微服务架构设计思想 导致成功的微服务项目屈指可数，只听说微服务的好，却不知微服务的坑

• 架构好了，框架怎么选择？ dubbo、Spring Boot/Cloud、Istio、Vert.x、还是自研？大一点的企业都会选择自研，但自研又会遇到如下问题：

  • 无法传承，框架的研发人员离职后没有可以接手

  • 上手难度大，很多框架喜欢重复造轮子，做出来的与业界主流思想/标准格格不入，导致学习培训成本很高

  • 功能片面，不通用，服务框架讲求通用性，尽量让整个公司使用同一套规范以方便维护，但很多框架只实现了某些特定场景的功能，无法通用化

  • 维护成本高，尤其是对于完全自研的框架，往往需要专职人员维护

  • 与主流脱节，无法分享微服务化、容器化、服务网格化的红利

没有合适的微服务框架 导致人员技能要求高、项目研发成本高企

• 框架选型也有了，但怎么测试、发布与运维？都在说容器化，要怎么做？

缺少一体化的研发流程支撑 导致各项目规范不统一、发布效率低、容器化问题频出

Dew架构思想

上述问题是Dew必须面对的，应对的设计核心理念是：

提供微服务架构指南 + 扩展主流微服务框架 + 标准化DevOps流程

提供微服务架构指南

项目要上微服务，其架构思想是前提，《微服务架构设计》(https://github.com/gudaoxuri/Microservices-Architecture) 做为入门书籍非常合适。

扩展主流微服务框架

1. 简单，用最通用的、标准的、开发人员都熟悉的开发模型

2. 全面，尽量重用市场已有能力实现，减少框架自身的维护成本

3. 轻量，原则上不引入高侵入性的三方框架/类库

4. 可替换，只做扩展，尽量不修改基础框架代码，开发人员完全可以直接基于基础框架开发

5. 主流，整合流行的微服务框架

实现上我们选择 Spring Boot 这一业界主流框架，对上兼容`Spring Cloud` 与 Istio。

标准化DevOps流程

1. CICD流程支持，自动化依赖管理、测试、质检、打包与发布

2. 全面容器化，所有环境均为容器方案

实现上我们选择 Gitlab CI 为基础对其进行扩展。

一言蔽之， ``Dew`` 致力于成为微服务一站式解决方案。