Spring Boot与微服务在花椒的实践
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成该任务。在全部状况下，每一个任务表明着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。
花椒的服务，不管是和前端靠的比较近的：好比H5官网；仍是APP服务：好比用户、直播、经济系统、云控等服务，都是使用PHP开发的。选择PHP的缘由以下：
PHP的开发效率高。无需编译，开发调试速度快。前端
团队在PHP方面积累的经验丰富：java
成熟的轻量级框架：Web框架QFrame，数据库QFrameDB，服务内部调用SDK：PepperClient，异步消息队列SDK：ProcessClient等git
丰富的LNMP调优经验。github
成熟的持续集成：发布系统。spring
HULK团队提供稳定高效的私有云解决方案：基于LNMP架构下的 Web服务管理：机器管理，Nginx等配置管理，MySQL、Redis等存储服务。数据库
工做中碰到的技术问题：
服务治理代码和业务代码耦合度高，不通用。使用Nginx + Lua + 降级代码。降级代码写到业务代码中，新增降级须要新写代码，没有一套通用降级，治理方案，耦合度高，影响业务稳定性。apache
团队维护成本高。服务是分模块的，你们各自维护各自的服务，底层没有核心模块，不一样服务之间充斥着重复代码，各自为战，复用性不足。举例：错误码不少服务是重叠的。后端
服务升级的技术成本很大。举例：经济系统虚拟货币服务分库提高支付能力，因没有成熟的组件， 须要人肉手写分库代码，更须要长时间的回归测试，压力测试才能上线。swoole
服务扩容速度慢，须要申请资源，部署，测试，上线。网络
服务优化，提高单机性能受限框架上限。受限于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开发天下，Spring Boot推出后更加赢得广大Java开发者青睐，随后推出的Spring Cloud微服务整套体系，Spring通过十多年的发展已很是成熟，生态也比较完善。
选择
选择Spring Boot 2做为微服务第一步基础，缘由以下：
成熟稳定，社区热度极高，相关资料不少，问题方便解决；
极大地提升了开发效率：使用注解、约定优于配置原则，大大减小了Spring Bean的配置文件；
方便部署，项目可独立打成jar包，无需依赖Web容器；
与微服务相关框架方便集成，几个注解搞定注册中心、配置中心等集成；
提供运行时的应用监控，actuator监控健康；
方便集成第三方http、gRPC组件，跨语言与PHP和Go项目交互。
ORM框架选择：
选择MyBatis，相对于Hibernate更轻便灵活，相对Spring JdbcTemplate功能更强大，使用mybatis-generator能够根据表反向生成model，提高开发效率。
Web容器选择：
选择Undertow：
Undertow在高负载状况下性能和稳定性要明显优于Tomcat；
比Tomcat更轻便。
开发规范：
选择安装阿里开源的代码规约扫描插件：Alibaba Java Coding Guidelines，能规范你们代码风格，检测潜在的异常，提早发现问题。
最终初步搭配：Spring Boot 2 + MyBatis Undertow做为Web容器打入jar包中。
稳步改进
活动项目结构以下：
activity-java活动业务包
activity-core活动核心包
common-core公共包
pepper-client花椒client包
pepper-statistics花椒统计监控包
pepperbus-client花椒消息总线client包
迭代后的现状架构图：
优化与改进：
持续集成发布由Jenkins改成GitLab。
使用GitLab优势：
集成Code Review插件，方便代码审核；
CI/CD自动发布部署，项目.gitlab-ci.yml文件配置好后，当开发分支合并到测试分支，自动编译打包、运行测试用例、部署到测试环境，正式环境发布、回滚也是轻松在Web界面点击几个按钮完成；
集成Kubernetes。
注册发现服务，选择Euerka/Nacos。
CAP理论指出，一个分布式系统不可能同时知足C（一致性）、A（可用性）和P（分区容错性）。因为分区容错性在是分布式系统中必需要保证的，所以咱们只能在A和C之间进行权衡，在此ZooKeeper保证的是CP，而Eureka则是AP，固然后起之秀阿里开源的Nacos，也值得研究考虑。
其它：
使用OpenFeign做为成为一个轻量级REST API客户端，很方便访问其它http接口，加个配置Hystrix和一个熔断实现类就能够实现熔断；
使用SLF4J的MDC生成TraceId为了将来构建全链路监控作基础；
基于注解+ Springel + Redis实现防并发、幂等性等。
对外Gateway网关；
注册中心Euerka；
配置中心；
日志服务；
服务治理中心；
Wayne + Kubernetes容器化。
Service Mesh（服务网格）： 下一代微服务？
什么是Service Mesh？
服务网格（Service Mesh）是致力于解决服务间通信的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，Service Mesh一般是经过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一块儿来实现，而无需感知应用程序自己。
为何须要Service Mesh？
有了Spring Cloud整套微服务架构，为何咱们还须要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/