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