微服务实践目录,可以参见连接。 项目对接
公司构建大中台之后的事情。 背景:在作者的0.微服务方法论-1.微服务落地事项、04.软件产品公司竞争力、05.为什么公司都在提大中台?等文章中提到了很多关于公司怎样认识、理解与微服务微服务。在人的认知是需要过程的不可能一次就对一项事物深入的理解。所以,对于微服务中不只有前面的优点、可行性等方面。它其实是对人的认知的一种挑战。
微服务是一直在变化的。这也是微服务的一大特点,可以为业务提供很强的创新能力。那微服务具体会像那个方向变化?变化过程中会遇到怎样的问题?接下来我们就讨论这部分内容。 变化:在学物理的时候,都会对运动有一种基本认识:运动是绝对的,静止是相对的。在软件行业也需要有这种方式,例如:需求有专门管理需求变更的方法、软件过程管理在不断的发展、技术在不断的升级等等。相对于前面的变化来说,对于一个互联网产品公司所关注的业务形态、盈利模式、客户特征、运营指标等等。 对于互联网产品公司的怎样快速满足业务形态变化,适应盈利模式的叠加,适应各种类型的客户特征就成为重中之重。那对于需求,过程,技术,运维需要做才能适应这种高度不确定的办法。 VUCA
在VUCA时代,指导我们在这个时代的做事方式。需要全局性,前瞻性的思维模式考虑怎样适应多变的世界。微服务就是能够更好的适应多变的情况。下面以构建、变化、适应的方式说明适应方式。
构建过程是产品最开始构建基础设施的过程。这个时候会做大量的分析、设计工作、管理规范等等。以这些思考,规范等内容指导之后的产品过程。所以就显得这个过程很重要。这个过程为之后奠定产品发展的基础,这里针对需求管理,过程管理,技术选型等的思考可能会影响整个公司声明周期。 在这样的前提下公司起步阶段是非常重要的一个阶段,需要公司管理者有能力制定各种规范与抉择。针对于其他方面的管理工作会在之后的文章中进行讨论。这里我们讨论技术方面的内容:
随着业务的发展和人们对行业、对业务的认识的逐渐深入,人们会对业务进行重新设计与重新规划。这是一种内部产生变化的需求。还有一种是外部产生变更的情况,外部认为对接公司产品有意义,值得付出时会进行第三方对接。 针对第一种变化,如果是业务形态发生了变化,那么接受业务的变更到核心服务群中即可。针对内部需求变化还有另外一种比较难处理的。就是在业务逐渐的发展之后,原先业务稳定发展,并能持续进入盈利。现在需要发展出新的业务增长点以支撑公司盈利的持续增长。这个时候就需要构建新的系统。 那如果是发展出新的业务,新的业务的技术微服务怎样管理?直接加入的系统基础服务中?另起系统重新管理?这里就带来了变化。这里也把问题遗留下来,下面一起解决。
上面提到了几个问题:
适应就是为了在系统遇到各种各样的问题时,怎样让系统适配这些情况。这些处理策略就是我们的工程规范。这里阐述几个观点,说明作者对于这几个问题的基本思考:
上面提到的核心微服务系统群的概念,可以参加大中台的概念。但是它是更倾向于稳定,通用性的业务。它是经过高度抽象并提供原子操作的核心系统,就像微内核系统中内核。外部的所有内容都是以插件的形式插入到系统中。 在本系列前面的一篇文章【0.微服务方法论-1.微服务落地事项】中大概整理了公司构建微服务时需要考虑的内容。也需要考虑核心微服务群的持续改进过程。所以,核心微服务既需要满足不断扩展的需要,又要满足稳定可靠的要求。那怎么满足即变化又稳定的要求呢?解决上面提到的三个问题就可以解决这个问题。
不管在生活、学习、工作中都需要持续的改进,持续的深入认识某一件事物。就像上面所说的新业务需要不断的加入,原先业务需要不断的优化。所以需要持续改进的过程。这里的持续改进就需要持续的业务运营数据反馈与持续的添加系统。这个也可以在之后的文章中说明。 总结:在建设完成微服务群之后,需要考虑之后的很多事情。这里说明的持续改进只不过是其中的一小部分。我们可以从不同的角度进行考虑以更好的指导之后的技术工作。 参考: |
|