springboot与微服务从0到1 的实践

来源公众号花椒技术 ，

作者花椒服务端

Java微服务初探

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。

01

现状与选择

现状

花椒的服务，无论是和前端靠的比较近的：比如H5官网；还是app服务：比如用户，直播，经济系统，云控等服务，都是使用PHP开发的。选择PHP的原因如下：

• PHP的开发效率高。无需编译，开发调试速度快。
• 团队在PHP方面积累的经验丰富：
• 成熟的轻量级框架：Web框架QFrame，数据库QFrameDB，服务内部调用SDK：PepperClient，异步消息队列SDK：ProcessClient等
• 丰富的LNMP调优经验。
• 成熟的持续集成：发布系统。
• HULK团队提供稳定高效的私有云解决方案：基于LNMP架构下的 Web服务管理：机器管理，Nginx等配置管理，Mysql，Redis等存储服务。工作中碰到的技术问题：
• 服务治理代码和业务代码耦合度高，不通用。使用 nginx + lua + 降级代码。降级代码写到业务代码中，新增降级需要新写代码，没有一套通用降级，治理方案，耦合度高，影响业务稳定性。
• 团队维护成本高。服务是分模块的，大家各自维护各自的服务，底层没有核心模块，不同服务之间充斥着重复代码，各自为战，复用性不足。举例：错误码很多服务是重叠的。
• 服务升级的技术成本很大。举例：经济系统虚拟货币服务分库提升支付能力，因没有成熟的组件， 需要人肉手写分库代码，更需要长时间的回归测试，压力测试才能上线。
• 服务扩容速度慢，需要申请资源，部署，测试，上线。
• 服务优化，提升单机性能受限框架上限。受限于LNMP每个请求独享一个进行，同步IO的机制而变得艰难，可以选择更换框架为swoole，选择异步Redis的库，这都需要大量的基础调研，测试，业务代码会被改的面目全非，项目周期会冗长。整个后端的微服务做到了分拆：用户，直播，消息，经济系统，云控等，项目的开发效率高，但是维护的工作对工程师得能力要求极高，治理，服务扩容，缩容，技术升级等问题还是困难重重，步履维艰。而java体系的spring cloud在服务注册发现、熔断限流、服务网关、分布式配置等一道解决，而不是在php方案上自己找开源去拼凑重构，这方面java更成熟和成体系，而且java体系在新兴的微服务架构Service Mesh中融合更好。

现有微服务解决方案

阿里

阿里使用java做为主要开发语言，开源出框架也很多，分布式和微服务框架：Dubbo、 Spring Cloud Alibaba 这两个框架 。Dubbo曾经一度停止维护，后来重新维护并开源到apache，Dubbo只能称为服务治理框架但距离系统完善微服务体系还有很多不足；Spring Cloud Alibaba 是基于Spring Cloud开源的一套微服务一站式解决方案，目前是一个孵化项目，它的仓库也位于Spring Cloud孵化器中，很具有发展潜力。

项目地址 dubbo：https://dubbo.apache.org 、spring-cloud-alibaba：https://github.com/alibaba/spring-cloud-alibaba

腾讯

腾讯开源微服务框架：Tars 是腾讯从2008年到今天一直在使用的后台逻辑层的统一应用框架，它集可扩展协议编解码、高性能RPC通信框架、路由与发现、发布监控、日志统计、配置管理等于一体，但社区的活跃度不怎么高，文档也不够完善。

项目地址：https://github.com/TarsCloud/Tars

华为

华为的ServiceComb框架: HWCloud在2017年6月发布开源的一款微服务框架，集服务注册、发现、通信和微服务治理能力为一体，并默认提供集中化配置，目前已开源到apache，值得关注。

项目地址：https://servicecomb.apache.org

spring

不用说，写过java的人都认识，spring自2003年开源至今，强大的生命力不断更新迭代，java框架活跃度No1，基本一统web开发天下，springboot推出后更加赢得广大java开发者青睐，随后推出的springcloud微服务整套体系，spring经过十多年的发展已非常成熟，生态也比较完善。

选择

选择springboot2作为微服务第一步基础，原因如下：

• 成熟稳定，社区热度极高，相关资料很多，问题方便解决。
• 极大地提高了开发效率：
  使用注解、约定优于配置原则，大大减少了springBean的配置文件；
• 方便部署，项目可独立打成jar包，无需依赖web容器；
• 与微服务相关框架方便集成，几个注解搞定注册中心、配置中心等集成；
• 提供运行时的应用监控，actuator监控健康；
• 方便集成第三方http、grpc组件，跨语言与php和go项目交互；

orm框架选择：

• 选择mybatis，相对于hibernate更轻便灵活，相对springjdbcTemplate功能更强大，使用 mybatis-generator 可以根据表反向生成model，提升开发效率

web容器选择：

• 选择undertow，
  1、undertow在高负载情况下性能和稳定性要明显优于tomcat；
  2、比tomcat更轻便；

开发规范：

• 选择安装阿里开源的代码规约扫描插件：Alibaba Java Coding Guidelines，能规范大家代码风格，检测潜在的异常，提前发现问题。

最终初步搭配：
springboot2 + mybatis undertow作为web容器打入jar包中

02

稳步改进

要既保证支持现有业务的推进，又得保证系统稳定，以活动项目作为先锋，先趟一遍坑。

活动项目结构如下：

• activity-java 活动业务包
• activity-core 活动核心包
• common-core 公共包
• pepper-client 花椒client包
• pepper-statistics 花椒统计监控包
• pepperbus-client 花椒消息总线client包

迭代后的现状架构图

优化与改进

1.持续集成发布由jenkins改为gitlab
使用gitlab优点：

• 集成Code Review插件，方便代码审核；
• CI/CD自动发布部署，项目.gitlab-ci.yml文件配置好后，当开发分支合并到测试分支，自动编译打包、运行测试用例、部署到测试环境，正式环境发布、回滚也是轻松在web界面点击几个按钮完成；
• 集成Kubernetes

2.注册发现服务，选择eureka/Nacos，
CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡，在此Zookeeper保证的是CP, 而Eureka则是AP，当然后起之秀阿里开源的Nacos，也值得研究考虑。

3.其它

• 使用openfeign作为成为一个轻量级REST API客户端，很方便访问其它http接口，加个配置Hystrix和一个熔断实现类就可以实现熔断；
• 使用slf4j的MDC生成traceId为了未来构建全链路监控做基础；
• 基于注解+springEl+redis实现防并发、幂等性等；

03

展望未来

计划中部署如下微服务组件：

1. 对外gateway网关。
2. 注册中心euerka。
3. 配置中心。
4. 日志服务。
5. 服务治理中心。
6. wayne+k8s 容器化。

流程图__1_

Service Mesh（服务网格）：下一代微服务？

什么是Service Mesh？

服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh通常是通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，而无需感知应用程序本身。

为什么需要Service Mesh？

有了springcloud整套微服务架构，为什么我们还需要Service Mesh？经过上面的介绍不难发现，整个微服务要关注的组件太多了，在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，而且随着规模和复杂性的增长，服务越来越难以理解和管理。如果用TCP协议类比就很恰当，在TCP协议未出来之前，开发人员需要自己考虑服务间数据包的传输、粘包、网络异常重试等问题，网络传输代码与业务代码耦合，而TCP协议出来后，开发者不用关心网络传输具体实现，有更多精力实现自己的业务，网络传输TCP协议就对应服务网格的Sidecar模式，Sidecar模块代理所有非业务功能。

Service Mesh 有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

细节图：

鸟瞰图：

Service Mesh相关框架：第一代以Linkerd和Envoy为代表 ；第二代以Istio和Conduit为代表。

大厂在Service Mesh上的实践

国内大厂已有服务网格的相关实践，蚂蚁金服、华为、腾讯等公司有成熟运营和迭代，这也是将是发展的必然趋势。
Service Mesh实践资料清单 https://www.servicemesher.com/awesome-servicemesh/

参考相关链接

springcloud
https://springcloud.cc/
https://spring.io/projects/spring-cloud

什么是Service Mesh
https://jimmysong.io/posts/what-is-a-service-mesh/

Service Mesh实践资料清单：
https://www.servicemesher.com/awesome-servicemesh/

istio中文网：
https://istio.io/zh/docs/concepts/what-is-istio/

Pattern: Service Mesh
https://philcalcado.com/2017/08/03/pattern_service_mesh.html