认识达内从这里开始

我们在前几期的文章中给大家简单介绍了程序员在学习微服务架构开发的时候需要掌握的一些开发原则等内容，而本文我们就继续来学习一下，微服务架构实践流程都有哪些。

微服务具象以后，就是微服务框架，毕竟一切理念的实现都是基于微服务框架的，微服务框架解决了微服务独立后的技术问题，比如通信、寻址、限流等。所以微服务系统先需要开发使用微服务框架，基于此做设计，等开发阶段完成，运行时自然就可以部署成微服务系统，微服务运行中，需要运行观测、策略配置、问题调试等，这就是整套微服务的使用流程。

但是微服务化的建设流程，也按照使用的时候这种顺序，就很难建设起来了。接下来根据我们公司在很多个微服务项目中的建设经验，梳理一下微服务建设的内容和顺序。

微服务运行态，也就是在测试、生产环境中，运行中的微服务系统，做治理、观测、配置的管理平台。微服务的优势也相应的带来了很多不利，比如服务太多难以管理、问题出现不容易定位、彼此间依赖关系不明确、策略更改不好操作等等。那么运行态的观测平台或者支撑平台，就是解决一切运行中的问题，包括变更发布、运维监控、日志查看等等。

微服务开发态，规范都是给开发、部署的时候定的，比如标准的协议、标准的报文，固定的组件地址、固定的探针等，因此开发的时候需要引入SDK，插入注解，而且还要解决依赖包之间的冲突。当然服务契约也是重要的一块，这就跟设计也有了关联，通常服务契约是设计的成果，也用来检验开发的质量。事情一旦深入，也就会复杂，通常还会建设一个微服务开发支撑平台，作为开发态的管理。

统一发布管理，一个部署包，穿梭于多个环境，每次部署都需要专门的运维、完整的部署脚本或文档，并且需要将各类组件的地址，一次一次的配置好，这工作着实有点庞大。所以需要一个可以管理多环境，支持容器、非容器的应用部署，并可以对接和管理好不同环境的制品库，用以做同一发布、部署平台。

这样的建设，也许很多人会很迷惑，为什么不从开发态开始建设，而要从运行态建设，然后开发态，后又补充中间的发布和部署?这样做是目前为止我们在很多项目实践中得出的经验，微服务化的理念已经提出来这么久了，现在做IT行业的基本上都有一些自己的理解和认识了，但是我们其实应该认清楚，我们看到的只是冰山一角，逐步建设、逐步认识、逐步学习，才能使我们真正认识微服务带给我们的利和弊。

选择从运行态入手建设，那么开发态的管理就只能从线下规范，但是运行态比较固定，比较容易看得清，因此建设的内容短期内推翻的可能性很低。通过开发态的建设，逐步看清微服务的架构以后，再建设开发态就比较容易理解，也更能趋利避害。但是如果从开发态开始建设，那么会受到运行态的组件选型、运行模式、部署架构、网络位置等等的影响，必须全面考虑清楚，只要有疏忽，就可能会推翻以建设的内容。

因此先从运行态入手，运行态建设完以后，我们基本上能定出来开发态需要注意的哪些规范和内容。同样的道理建设了开发态以后，就已经总结了很多发布部署需要注意的，然后建设容器、非容器的统一发布平台。这样基本上微服务化转型的体系，就已经清晰明了了。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。