导读
本篇文章是博云微服务转型系列第四篇。
在该系列前三篇文章中，咱们分享了微服务转型的懊恼、误区和建设第一步。之前在讲到微服务的时候，咱们分享过许多落地计划和实际总结，但对于微服务理念却较少地提及。起因是只讲理念有点空洞，而且炒理念的阶段也过来了。然而到当初这一步，咱们不得不把理念拿进去，用理念领导咱们微服务化建设的方向。
这是因为任何事件如果想有更深、更久远的倒退，通常都须要哲学或者理念的疏导，就像西方哲学对古代社会的影响，甚至大家纯熟应用的高级编程语言，也是使用西哲的形象、逻辑的思维，而后呈现了类、分层等技术。那么在微服务的建设中，咱们应该如何使用微服务的理念，既能实现微服务化建设落地，又不偏离总体的云原生指标呢？
01 微服务理念
微服务理念是 2017 年左右开始沉闷，而后进入到一个从设想到落地的过程，大家逐渐尝试也就逐渐陷于懊恼中，因为实际与现实的差距还是十分远。到往年，简直所有的企业都在思考数字化转型的建设，这是大势所趋，如果在当下的 IT 建设与将来云原生路线布局中，都能放弃清晰的思路，这样的企业切实难能可贵。兴许本文可能给正在困惑的建设者一些灵感，然而“运用之妙，存乎一心”，具体的建设状况还是要依据企业现状来进行。
咱们先看微服务的理念，上网轻易一搜就能够找到很多材料，说法根本对立：代替轻便的零碎，依赖新型的技术架构，实现零碎拆分成多个独立组件，独立的水平代表了每个微服务组件自在的水平，自由度越高就越有更多的可能性，次要劣势能够是以下这些：
独立的运行、部署，那天然能够独立的降级、变更、保护，也就能够视其业务量，做自在的扩缩容。并且操作单元小，自然资源节约就小，轻量快捷。
能够独立运行，那也就能够独立的开发，这样就能够在技术架构上解耦，只有遵循服务契约，提供相应的接口，那么开发应用的技术、语言、数据存储就都能够独立的建设。换句话说，如果须要依赖一个开发框架、语言都不同的服务，只须要理解接口和协定就行了，其余的能够不必关注。
能够独立的开发，那么开发团队就能够独立治理，这样在治理上效率就高了很多了。
微服务劣势有很多，然而最重要且对企业整体治理影响最大的就是以上这三个了。然而，短期内很难达到这样现实的指标。
如果就一个零碎看，拆成多个微服务，独立运行部署是很简略，很容易做到的，这也是我在误会中提到的场景。但如果是整个企业、银行的建设，咱们应该思考的是所有的零碎，都能够拆成独立部署的微服务，并且能够相互调用，当然同时还要做到拜访的管制。这就须要全行级的统一规划，对立技术框架和通信协议，当然还须要一个对立治理平台，用于运行中的治理。
独立开发看上去倒是很容易实现的，但真正使用好却是最难的，因为作为单体零碎设计、开发的理念曾经积重难返了，当零碎拆成微服务当前，理念却很难扭转，所以很多微服务零碎还是一个零碎版本一个零碎版本的演进，每个微服务甚至都没有版本。这也就是模式上的微服务，而实际上独立更新的劣势并没有施展进去。新型的理念须要技术架构、技术治理、技术研发，逐渐承受、扭转和习惯，短期内很难扭转。
独立的开发团队或者小组，这是须要在行政架构上做调整的，所以这一步也是最难扭转的。从治理的角度来讲，三个人的交换老本是最低的，所以最迷信的治理办法中，最小的治理单元是三个人，宏大的业务零碎在研发的治理是也同时面临着沟通和管理效率低的问题。微服务为其优化治理提供了可能性，但也须要逐渐适应和逐渐扭转。
总之，真正实现理想化的微服务，可能须要很长时间的建设、扭转和适应，这个过程怕是不能省的，只是这条路应该怎么走，从哪里动手才是正确的？
02 微服务建设之路
微服务具象当前，就是微服务框架，毕竟所有理念的实现都是基于微服务框架的，微服务框架解决了微服务独立后的技术问题，比方通信、寻址、限流等。所以微服务零碎首先须要开发应用微服务框架，基于此做设计，等开发阶段实现，运行时天然就能够部署成微服务零碎，微服务运行中，须要运行观测、策略配置、问题调试等，这就是整套微服务的应用流程。
然而微服务化的建设流程，也依照应用的时候这种程序，就很难建设起来了。接下来依据咱们公司在很多个微服务项目中的建设教训，梳理一下微服务建设的内容和程序。首先说微服务建设须要建设哪些内容：
上一篇曾经提到过微服务建设须要对立技术栈，也就是对立技术架构、技术组件、通信协议、通信报文等。对立之后能力便于管理，能力从全局动手布局，优化架构设计。研发部门防止了很多因技术不同，而须要做的简单的转换；运维部门也会因所有零碎应用同一套治理组件，而缩小运维工作量、节俭服务器资源。所以制订标准、推广标准是建设第一步，当然也包含根底组件的搭建。
- 微服务运行态，也就是在测试、生产环境中，运行中的微服务零碎，做治理、观测、配置的治理平台。微服务的劣势也相应的带来了很多不利，比方服务太多难以治理、问题呈现不容易定位、彼此间依赖关系不明确、策略更改不好操作等等。那么运行态的观测平台或者撑持平台，就是解决所有运行中的问题，包含变更公布、运维监控、日志查看等等。
- 微服务开发态，标准都是给开发、部署的时候定的，比方规范的协定、规范的报文，固定的组件地址、固定的探针等，因而开发的时候须要引入 SDK，插入注解，而且还要解决依赖包之间的抵触。当然服务契约也是重要的一块，这就跟设计也有了关联，通常服务契约是设计的成绩，也用来测验开发的品质。事件一旦深刻，也就会简单，通常还会建设一个微服务开发撑持平台，作为开发态的治理。
- 对立公布治理，一个部署包，穿梭于多个环境，每次部署都须要专门的运维、残缺的部署脚本或文档，并且须要将各类组件的地址，一次一次的配置好，这工作着实有点宏大。所以须要一个能够治理多环境，反对容器、非容器的利用部署，并能够对接和治理好不同环境的制品库，用以做同一公布、部署平台。
这样的建设，兴许很多人会很蛊惑，为什么不从开发态开始建设，而要从运行态建设，而后开发态，最初又补充两头的公布和部署？这样做是目前为止咱们在很多我的项目实际中得出的教训，微服务化的理念曾经提出来这么久了，当初做 IT 行业的基本上都有一些本人的了解和意识了，然而咱们其实应该认分明，咱们看到的只是冰山一角，逐渐建设、逐渐意识、逐渐学习，能力使咱们真正意识微服务带给咱们的利和弊。
抉择从运行态动手建设，那么开发态的治理就只能从线下标准，然而运行态比拟固定，比拟容易看得清，因而建设的内容短期内颠覆的可能性很低。通过开发态的建设，逐渐看清微服务的架构当前，再建设开发态就比拟容易了解，也更能趋利避害。然而如果从开发态开始建设，那么会受到运行态的组件选型、运行模式、部署架构、网络地位等等的影响，必须全面思考分明，只有有忽略，就可能会颠覆以建设的内容。
因而先从运行态动手，运行态建设完当前，咱们基本上能定进去开发态须要留神的哪些标准和内容。同样的情理建设了开发态当前，就曾经总结了很多公布部署须要留神的，而后建设容器、非容器的对立公布平台。这样基本上微服务化转型的体系，就曾经清晰明了了。
点击 BoCloud 博云理解更多解决方案