开源php探针_小团队真的适合引入SpringCloud微服务吗？

建筑师

我们都是建筑师！

架构未来，你来吗？

微服务时代

容器化时代

概括

微服务是否适合小团队，这是一个见仁见智的问题。

回过头来看现象，随着业务复杂度的增加，单体应用变得越来越大，就像一个类的代码行数越来越多。分而治之，拆分成多个类应该是更好的解决方案。因此，将一个大型单体应用拆分成多个小应用更符合这种分而治之的思路。

当然，微服务架构不应该是一个小团队一开始就考虑的问题，而应该是一个逐渐演进的结果，尤其需要警惕过度设计。

公司背景是提供SaaS服务，也为大客户提供定制化开发和私有部署，在不到两年的时间里，技术架构经历了从单体到微服务再到容器化的过程。

单一应用程序的时代

早期开发就两个人，没必要考虑微服务，但受之前公司的影响，一开始就决定前后端分离，不用考虑SEO问题，所以干脆就做成了SPA单页应用。

顺便说一句，前后端分离并不一定意味着不能进行服务端渲染。例如对于电商系统或者一些匿名访问的系统，增加一层薄薄的 View 层是一个不错的选择，无论是 PHP 还是 。

部署架构上，我们使用Nginx代理前端HTML资源，根据接收请求时的路径反向代理到8080端口来实现业务。

接口定义

接口是按照标准定义的。

持续集成 (CI)

由于初期团队成员均有大型团队工作经历，对质量管控、流程管理等有共同的需求，因此在开发之初就引入了一套集成测试系统，可以直接针对接口开发测试用例，统一执行，并计算覆盖率。

一般来说，自动执行的代码就是单元测试（Unit Test），我们叫它集成测试，因为测试用例是针对API的，包括数据库读写，MQ操作等，除了对外部服务的依赖外，基本都符合真实的生产场景，相当于直接在Java层面干事。

这在开发初期给我们提供了极大的便利。不过值得注意的是，由于数据库等资源的引入，在准备和清洗数据时需要考虑的问题更多，比如如何控制并行任务之间的测试数据，让它们互相不影响。

为了让这个过程自动化运行，自然需要引入它。

当开发人员提交代码时，会触发编译代码并进行集成测试，完成后生成测试报告，测试通过后再进行代码重构。在单体应用时代，这样的CI架构已经足够有用了。有了集成测试的覆盖，在保持API兼容性的情况下，代码重构会变得更加自信。

微服务时代的服务拆分原则

从数据角度看，最简单的办法是看数据库表之间的关联是否比较少，比如最容易分离的通常是用户管理模块。从领域驱动设计（DDD）角度看，一个服务其实就是一个或者几个相关的领域模型，用少量的数据冗余来定义服务边界。

多个领域对象可以通过领域服务在单个服务内进行协作。当然，DDD 更加复杂，要求领域对象设计应该是充血模型，而不是贫血模型。

从实践角度看，拥塞模型对于大多数开发人员来说非常困难，哪些代码应该属于行为，哪些属于领域服务，往往非常考验人员的水平。

服务拆分是一个很大的工程，往往需要几个最熟悉业务和数据的人一起讨论，甚至需要考虑团队架构。最终的效果是服务边界清晰，无循环依赖，避免双向依赖。

框架选择

由于之前单体服务使用了 boot，框架自然也选择了云。其实我个人认为微服务框架不应该限制技术和语言，但是在生产实践中我们发现，dubbo 和云都具有侵入性，在将应用集成到云系统中时发现了很多问题。或许未来 mesh 会是一条更加合理的发展路径。

这是典型的云用法

就像上面提到的，一旦要集成异构语言，就需要自己处理服务注册、服务发现、服务调用、断路限流等。

关于Zuul我再多说几句，Sprin Cloud提供的Zuul已经精简过，删除了动态路由功能（实现）。还有一点就是Zuul的性能一般，由于采用同步编程模型，对于IO密集型等后台处理时间长的环节，很容易把线程池撑满，因此如果Zuul和主进程放在同一台物理机上，在流量大的时候Zuul的资源消耗会非常大。

实际测试也发现Zuul和直接调用的性能损耗在30%左右，在并发压力大的时候更加明显。现在云主推，支持异步编程模型，后续架构优化可能会采用它，或者直接使用Kong这种基于nginx的网关来提供性能。当然同步模型也有优势，编码也更简单，后面的文章会提到如何使用它建立链路追踪。

架构转型

经过半年多的改造和新需求的加入，单体服务不断拆分，最终形成了十多个微服务，并针对BI搭建了Spark。初步形成了两大体系，微服务架构的在线业务系统（OLTP）+Spark大数据分析系统（OLAP）。数据源从只有MySQL增加到ES和Hive。多数据源之间的数据同步也是一个值得讲的话题，但内容太多，本文就不一一介绍了。

自动部署

相比CI，持续交付（CD）的实现更加复杂，在资源不足的情况下，我们还没有实现CD，只是实现了自动化部署。

由于生产环境需要通过跳转服务器进行操作，所以我们生成jar包传输到跳转服务器，然后部署到集群中。

简单粗暴的部署方式对于小规模团队开发来说已经足够了，但是在部署前需要保证测试（手工测试+自动化测试）到位。

链接追踪

目前开源的全链路追踪服务有很多，国内比如cloud+、美团的CAT等，目的是当一个请求经过多个服务时，通过一个固定的值来获取整个请求链路的行为日志，以此为基础进行耗时分析，衍生出一些性能诊断的功能。但对于我们来说，首要目的是能够快速定位异常发生在哪个服务，发生问题时整个请求链路是什么样的。

为了方案轻量，我们在日志中打印 和 来标记链路，在产生唯一请求的时候，相当于一条次要路径，一开始跟 一样，但是进入线程池或者消息队列之后，就加了一个标记来标识唯一路径。

例如一个请求发送一条消息到MQ，这条消息可能被多个消费者消费，此时每个消费者线程都会生成一条消息来标记消费链路，添加的目的是避免过滤掉过多的日志，实现如图所示。

简单来说，通过将所有调用串联到单个服务中，跨服务调用时，将信息转换为Http，被调用方获取Http后重新构建并再次放入，如此循环往复，保证不丢失。如果进入MQ，可以进行信息转换（根据实现）。

当日志聚合到日志系统之后，如果出现问题，只需要捕获异常或者进行定位就可以了。

运维监控

在容器化之前，采用的是++方案，作为探针，收集jvm、mysql等资源信息，并写入，最后将数据可视化，boot可以配合jvm的暴露，整个方案零编码，只需要配置一下时间。

容器化时代的架构变革

因为在微服务之初就规划了容器化，所以架构上没有太大的变化，但是每个服务都会建立一个

涉及修改的部分包括：

CI 添加了图像构建步骤

在自动化测试期间，数据库升级与应用程序分离，并制作成单独的映像

在生产中，eruka 被 k8s 自己的替换

原因如下。

云与 的集成

我们使用的是，可以认为是k8s企业版，有自己的概念，一个下面有多个pod，每个pod都是一个服务单元，相互调用的时候k8s会提供默认的负载均衡控制，调用方只需要写被调用方的就可以了。这个和cloud fegin提供的功能一模一样。

也就是说，服务治理可以用k8s来解决，那为什么要取代它呢？其实上面也说了，云技术栈支持异构语言，我们有很多实现的BFF（for），这些服务如果想集成到云中，服务注册、负载均衡、心跳检查等都要自己实现。

如果以后加入其他语言架构的服务，这些轮子就得重新造，综合考虑这些原因，决定用提供的网络能力来替代Eruka。

由于本地开发和联调依然依赖eruka，因此仅通过生产中配置参数来控制。

eureka.client.enabled` 设置为 false，停止各服务的eureka注册
`ribbon.eureka.enabled` 设置为 false，让ribbon不从eureka获取服务列表
以服务foo为例，`foo.ribbon.listofservers` 设置为 `http://foo:8080`，那么当一个服务需要使用服务foo的时候，就会直接调用到`http://foo:8080

CI 转型

CI 主要的改造就是增加了一个编译打包镜像的过程，部署的时候直接从里面拉取镜像。还有一个就是数据库升级工具，我们之前用的是数据库升级工具，在应用启动的时候自动执行 SQL 脚本。

随着服务实例数量的增加，一个服务的多个实例同时升级的情况很常见，虽然升级过程中会使用数据库锁来防止并发，但是这会导致锁定的服务的启动时间更长。

从实际升级流程来看，将可能发生的并发升级转化为单一流程可能更为可靠。另外后期分库分表的架构也会使得应用启动时自动升级数据库变得困难。综合考虑后，我们将升级任务拆分，每个服务都有自己的升级项目，并将进行容器化。

使用时作为一次运行的工具，即run -rm方式，后续还支持设置目标版本的功能，对私有化项目跨版本升级起到很好的作用。

对于自动部署，由于服务之间存在上下游关系，例如etc.等基础服务是依赖于其他服务的，部署也是有顺序的，基于doing可以很好的解决这个问题。

概括

其实上面每一点都可以写成一篇很深入的文章，微服务的架构演进涉及到开发、测试、运维等各个环节，需要团队内部多个工种的密切配合。

分而治之是软件行业解决大系统问题的唯一方法，作为一个小团队，我们在开发过程中没有盲目追求新的东西，而是通过面向服务的方法解决问题。

另一方面，我们也意识到微服务对人的要求、对团队的挑战比过去更高、更大，未来还有很大的探索和演进空间。

·END·
作者：Dean
来源：deanwangpro.com/2019/02/18/road-of-microservice
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!