我的微服务到底实现的怎么样？

随着容器化技术的成熟，以及容器编排技术自动化的发展，应用程序开发越来越多的向薇服务架构眼睛，那么我们经常遇到的一个问题，就是我们的微服务实现的怎么样？我们实现的微服务是真的为服务吗？还是只是包装变了一下。

之前我写了两篇文章，

• 微服务实现三三两两原则，从微服务 12 条金规实践出发来理解为服务开发中的注意事项
• 用DDD领域驱动设计方法对业务进行划分。

今天这边文章想从更大的颗粒度上去认识甄别判断为服务的实现的成熟度，这个有助于从外部，以及整体来理解我们的微服务程序的成熟度。

单一性原则

我认为这可能是最重要的一个原则。 一个微服务只解决一个领域问题，或者我们认为是一个商业问题，所有的更改变动只会一个核心问题。 当然，面对一个复杂的领域问题，这个也是比较难以直接给出答案的。 但是如果没有遵循这个原则，往往会带来很多的痛点。 比如：

• 频繁升级软件，但是呢，又并不能够带来特性。 也就是不能带来商业利益维护的成本高过于他带来的效益。
• 程序过于复杂。，当出现问题的时候调试。，修复新手接手非常困难，这些都说明这个程序乘载了太多的功能和责任。
• 需要暴露的接口太多了。这个主要要从开发人员数量，维护人员数量来判断；
• 前后端分离
• 服务网关

适合容器云部署。

那么什么程序，不适合云部署呢？ 我们可以从下面几个指标来看。：

• 内存占用
• 启动速度 一般要求微服应用程序谨慎选择基础镜像， 优化最终镜像文件，去除不必要依赖，数据软件分离 来保障为服务程序运行时的小尺寸灵活启动。 。 甚至可以采用云原生的开发框架。 直接构建出能够原生运行，于容器环境的二进制文件，从而达到内存小启动快极大提高。。
• 标准服务restful服务接口 为什么会有对Rest的接口的需求，主要是在微服务开发的背景下为服务之间的契约 ，以及依赖要尽可能的隔离以及自服务。所以当你提供一个服务接口的时候，还需要提供调用文档。，集成测试接口等等一系列问题Russ的API呢，提供了良好的生态。 对于大部分Web base的用应用来说是非常适合的。
• 交付的软件是容器镜像形态。 我们知道传统的应用运行环境。都是基于物理几？操作系统，或者虚拟机。所以软件二进制的版本控制都是根据各自语言框架而不同。视频库呢，也需要管理各种各样的软件二进制形态，而对于容器云部署环境 我们统一都是用容器境下。，使用容器镜像仓库进行二进制输出的管理和版本控制。 这个必要性和优越性主要体现在。：
  • 统一不同语言的软件的发布和管理。
  • 减少依赖管理的复杂度，因为所有的依赖都打到镜像里面。

• 具备健康检查接口。 不同于传统的应用程序，部署在容器环境呢，都是平台字符物质管理的要求应用程序需要有健康检查接口才能完成容器应用的字修复,以及运行健壮性。

• 集中日志采集
• 集中性能，监控与告警。
• 分布式调用追踪。

部署升级维护简单

• 尽可能的要做到自服务。 我们在企业应用里面，经常遇到一个微服务有大量的依赖。，包括技术上，以及流程上环境等等，如果你去分析整个部署过程你会发现会有很多的事务性开销。 比如申请网络资源。，申请虚拟机资源，准备操作系统环境，配置等等；

所以一个微服务的很重要的一个特性，就是要快速开发测试发布一条龙，迭代中间不允许有太多事务性步骤。

• 要是和自动化维护的高效率很大程度上要利用现代化的DevOps工具方法以及理念。 这就要求我们的应用程序能够自动化。，依赖能够识管理。 比如存储。，数据库

• CICD Pipeline

• 基础设施代码化 这里的基础设施指的是在应用应用程序开发过程中，需要使用的开发工具，构建工具质量检查测试等等，为为服务服务的这些基础设施。 在具体实践中往往有两种模式。：
  • 一种是集中式的共用似的技术设施。
  • 一种是单单租户自服务的基础设施管理。

• 单一分支 发布管理 Trunk-based branch management 之所以强调，这一点是因为微服务程序，往往具备快速迭代。,快速演进的特征，他不同于传统应用大而全发布节奏相对缓慢。

  那么如果微服务程序还沿用原来的产品分支模式需要长期维护一个分支，导致多个分支，同时维护这种情况势必会减慢迭代速度增加团队负担。 使用单一分支模式，往往需要其他的一些配套措施:

  • 成熟的代码审查机制。
  • 采用特性开关模式来控制新功能实验功能的开关。
  • 甚至可以采用极限编程中的绝对编程来，保证代码质量以及软件迭代能力。

• 减少非业务功能的开发。 现代化的容器平台，提供很好的容器运营时环境包括服务发现，服务治理，配置管理，等等基础支撑，所以我们的应用程序要避免重复这种轮子，加重微服务应用开发的负担。

  另一个原因是传统的服务发现机制，对于代码有较强的侵入性，影响微服务的快速迭代，

  传统的微服务发现机制呢，也不是一容器话环境的部署，因为荣庆换环境运行IP是不固定的， 而传统的服务发现呢，往往依赖到固定IP来提供服务。

• 微服务程序的容错能力要强。 之所以要强调，这一点是因为在荣计划平台中，由于服务边界切割的比较小，所以呢进程间通信变成了网网络间通信，因此业务逻辑，功能之间，调用的出错，概率比传统模式要大很多，这就要求我们需要面向错误，进行设计，需要很好的容错设计。 这就要求我们的微服务。接口函数，需要额外考虑。
  • 重试机制
  • 超时
  • 熔断

---