0.微服务方法论-3.持续改进微服务

微服务实践目录，可以参见连接。

项目对接

公司构建大中台之后的事情。

背景：

在作者的0.微服务方法论-1.微服务落地事项、04.软件产品公司竞争力、05.为什么公司都在提大中台？等文章中提到了很多关于公司怎样认识、理解与微服务微服务。在人的认知是需要过程的不可能一次就对一项事物深入的理解。所以，对于微服务中不只有前面的优点、可行性等方面。它其实是对人的认知的一种挑战。

微服务是一种持续演进的模式。--演进式架构

微服务是一直在变化的。这也是微服务的一大特点，可以为业务提供很强的创新能力。那微服务具体会像那个方向变化？变化过程中会遇到怎样的问题？接下来我们就讨论这部分内容。

变化：

在学物理的时候，都会对运动有一种基本认识：运动是绝对的，静止是相对的。在软件行业也需要有这种方式，例如：需求有专门管理需求变更的方法、软件过程管理在不断的发展、技术在不断的升级等等。相对于前面的变化来说，对于一个互联网产品公司所关注的业务形态、盈利模式、客户特征、运营指标等等。

对于互联网产品公司的怎样快速满足业务形态变化，适应盈利模式的叠加，适应各种类型的客户特征就成为重中之重。那对于需求，过程，技术，运维需要做才能适应这种高度不确定的办法。

VUCA

在VUCA时代，指导我们在这个时代的做事方式。需要全局性，前瞻性的思维模式考虑怎样适应多变的世界。微服务就是能够更好的适应多变的情况。下面以构建、变化、适应的方式说明适应方式。

• 构建

构建过程是产品最开始构建基础设施的过程。这个时候会做大量的分析、设计工作、管理规范等等。以这些思考，规范等内容指导之后的产品过程。所以就显得这个过程很重要。这个过程为之后奠定产品发展的基础，这里针对需求管理，过程管理，技术选型等的思考可能会影响整个公司声明周期。

在这样的前提下公司起步阶段是非常重要的一个阶段，需要公司管理者有能力制定各种规范与抉择。针对于其他方面的管理工作会在之后的文章中进行讨论。这里我们讨论技术方面的内容：

编号	具体规范	内容	说明
1	工程规范	1.项目规范，项目中代码管理、配置管理、编译方法 2.测试规范，故障率规范、自动化测试规范 3.UI设计规范，规范色调、操作设计、布局规范等	主要是管理产品过程的
2	实施规范	1.技术选型规范 2.工作量评估规范	统一技术，管理公司内部的技术技术栈
3	运维规范	1.容量规划 2.安全规划 3.部署规划 4.升级方法 5.可用性规划等	规范运维，避免运维不稳定性
4	运营规范	1.指标规范 2.规范分析方法	规范化产品运营过程

• 技术规范
  技术方面的选型影响者之后系统的可扩展性，伸缩性，可用性等内容。所以，现在大部分公司在开始构建自己的系统的时候都会直接考虑微服务模式，并配合各种架构模式构建。技术选型方面就参照现在流行的几个技术栈就好。整体技术规划有了，技术选型也有了之后最大的问题就在于工程规范方面。

• 工程规范
  工程规范方面的一个问题在于怎样规划产品整体。以怎样的微服务的划分规则？怎样规划产品的核心服务层？第三方接入规范？等等都是需要考虑的内容。其实大中台已经为我们提供了很多思路。而这里要讨论的更多的是第三方的定义和第三方的技术规范。

  怎么定义第三方？所有除核心系统之外的系统都是第三方？还是只有外部的系统需要接入时才叫第三方？跟第三方之间的技术规范，行为规范怎么定义？

  这里可以先把问题留在这里，我们以逐步推进的方式解决这几个问题。

• 变化

随着业务的发展和人们对行业、对业务的认识的逐渐深入，人们会对业务进行重新设计与重新规划。这是一种内部产生变化的需求。还有一种是外部产生变更的情况，外部认为对接公司产品有意义，值得付出时会进行第三方对接。

针对第一种变化，如果是业务形态发生了变化，那么接受业务的变更到核心服务群中即可。针对内部需求变化还有另外一种比较难处理的。就是在业务逐渐的发展之后，原先业务稳定发展，并能持续进入盈利。现在需要发展出新的业务增长点以支撑公司盈利的持续增长。这个时候就需要构建新的系统。

那如果是发展出新的业务，新的业务的技术微服务怎样管理？直接加入的系统基础服务中？另起系统重新管理？这里就带来了变化。这里也把问题遗留下来，下面一起解决。

• 适应

上面提到了几个问题：

1. 怎么定义第三方？
2. 与第三方之间的技术对接怎样完成？第三方接口的行为规范怎么定义？
3. 新业务的微服务要加到核心服务群中吗？

适应就是为了在系统遇到各种各样的问题时，怎样让系统适配这些情况。这些处理策略就是我们的工程规范。这里阐述几个观点，说明作者对于这几个问题的基本思考：

1. 核心微服务系统群必须是稳定，有完整的运维规范，优化规范。
2. 核心微服务系统群只提供基本功能。不提供与业务有任何关系的服务。
3. 核心微服务系统群必须能够支持业务的不断扩展。必须提供相关的服务接口或SDK等。
4. 核心微服务系统群应是独立管理与部署的。核心微服务不受外部系统的干扰。

上面提到的核心微服务系统群的概念，可以参加大中台的概念。但是它是更倾向于稳定，通用性的业务。它是经过高度抽象并提供原子操作的核心系统，就像微内核系统中内核。外部的所有内容都是以插件的形式插入到系统中。

在本系列前面的一篇文章【0.微服务方法论-1.微服务落地事项】中大概整理了公司构建微服务时需要考虑的内容。也需要考虑核心微服务群的持续改进过程。所以，核心微服务既需要满足不断扩展的需要，又要满足稳定可靠的要求。那怎么满足即变化又稳定的要求呢？解决上面提到的三个问题就可以解决这个问题。

1. 怎么定义第三方？
   在核心服务群外的平台、系统、服务都是第三方系统。这样其他系统的建设不会影响核心微服务群。可以保证核心微服务群的稳定。

2. 与第三方之间的技术对接怎样完成？第三方接口的行为规范怎么定义？
   第三方的技术对接使用对外接口管理。不允许使用服务群内部的RPC调用，服务发现，服务注册，服务监控等的系统。这里可以保证运维时是一个独立的系统。也可以进行支撑扩展。

3. 新业务的微服务要加到核心服务群中吗？
   新业务的初始加入需要满足业务验证，业务验证之后才考虑是否需要加入核心服务群。考虑是否需要加入核心服务群，怎样抽象服务这些在之后的文章中进行说明。

• 持续改进

不管在生活、学习、工作中都需要持续的改进，持续的深入认识某一件事物。就像上面所说的新业务需要不断的加入，原先业务需要不断的优化。所以需要持续改进的过程。这里的持续改进就需要持续的业务运营数据反馈与持续的添加系统。这个也可以在之后的文章中说明。

总结：

在建设完成微服务群之后，需要考虑之后的很多事情。这里说明的持续改进只不过是其中的一小部分。我们可以从不同的角度进行考虑以更好的指导之后的技术工作。

参考：

VUCA