微服务架构咨询和实施

Posted 2021-04-14 远见先行

关于微服务架构规划咨询和落地实施，在博客上我专门讲过微服务架构，也讲过微服务架构和SOA，和ESB服务总线的区别，也专门写过阿里的《传统企业IT架构转型》这本书的读书笔记。从我最早在企业内部私有云PaaS平台建设中谈到的平台+应用的构建模式，到组件化和服务化架构，到最近1年阿里谈的最多的中台战略和中心化，以及从传统的持续集成谈到现在的DevOps最佳实践，从传统以虚拟机为调度单位的PaaS平台到现在以容器化为主流的轻量PaaS。

整个技术发展的相当快，最典型的特点就是轻快+高性能，即面临快速变化的业务，传统的重型架构已经不合适。这和企业管理是一个道理，越是组织架构复杂，层级越多的企业往往转型也就越困难，业务处理流程和执行效率越低下。

转回到互联网来说，业务变化快而且需要敏捷响应，那么我们的架构就必须轻量灵活，能够快速的适应变化，同时这种架构还必须要满足对高性能，高可靠性的要求。正是这个原因也可以看到，对于微服务架构，容器化和DevOps最早仍然是在互联网企业得到广泛的应用，并产生了大量的最佳实践。

那对于传统企业的IT部门是否需要引入微服务架构，其实答案很简单，即只要传统企业IT出现了业务需要快速敏捷响应的场景，那么就一定需要一种更加轻量高效的架构。首先要满足轻快的要求，其次才是满足降低成本的要求，业务驱动IT，IT建设最终为业务服务，那么企业IT部门就必须回答好建设的IT系统如何更好的为业务服务？

今年团队将大部分研发重心放到微服务架构上，还有一个核心原因就是微服务架构真正将团队原来在SOA，云计算，软件项目管理和过程改进，敏捷方法论方面的最佳实践融合在一起，而只有这些真正融合才可能为企业提供一个完整的微服务架构解决方案。

这篇文章之所以叫微服务架构咨询和实施，是想说明在帮助企业进行微服务架构转型和推进过程中，远行科技究竟可以提供哪些支持和服务能力，具体来讲可以分为如下几个方面：

架构咨询服务能力

团队首先能提供，也是相当重要的一部分能力就是架构咨询能力，即需要回答企业的传统IT架构如何转型微服务架构以及如何演进？其次需要回答究竟如何划分微服务模块或组件，或者类似阿里谈到的各个中心（类似产品中心，客户中心，订单中心，库存中心）等，再次还需要在划分好微服务模块后进行关键的业务流程和场景的梳理和分析，识别每个微服务模块究竟应该保留哪些微服务API接口。

归根到底还是我原来强调到的一句话，即业务能力组件化和组件能力服务化，咨询服务最终给企业提供的就是划分出最合适的模块单元，并识别最容易复用，粗粒度的微服务API接口。

在传统的ESB服务总线实施和集成项目中，我们进行的SOA架构咨询，服务架构和目录库规划仍然是我们提供的相当有价值的服务。不管是ESB总线，还是微服务网关，最终都是技术平台，真正重要的是最终接入到平台上的服务究竟如何？

微服务架构基础框架

注意这里的基础框架涉及到多个方面的内容，包括了Spring Cloud微服务架构框架，也包括了k8s+Docker容器，还包括了类似开发工具环境，Jekins，Maven，JUnit各种工具的集成，DevOps最佳实践的落地等。这些都和微服务架构密不可分。也是我常说的微服务架构+容器化+DevOps是三个最核心的内容。

远行不仅仅是将这些开源的工具包进行完整的组合，形成一套标准的组件化开发方法和工具模板，同时提供一个完整的管理平台，可以实现灵活的模块定义，服务接入，自动构建和打包，流水线管理和环境迁移，灰度发布等完整的DevOps过程。同时还将类似项目管理，缺陷管理和看板，类似用户故事的条目化需求管理和跟踪全部集成进来，形成一套参考敏捷方法论的软件支撑过程平台。

这些不是简单的工具累加，而是团队多年的最佳实践当然融合。

监控和运维支撑平台

相对于传统的业务系统间的接口服务集成，在实施微服务架构化后接口服务会呈现指数级的增长，虽然各个微服务模块更加容易进行组合，服务也容易灵活编排，但是在整个应用全部上线后对于诸多的微服务模块的自动化运维，实时动态监控和预警就成为相对关键的内容。

在阿里的《传统企业IT架构转型》这本书里面专门提到了鹰眼应用，即通过鹰眼应用实现了整个微服务架构下所有微服务模块，微服务API接口的实时监控，服务链监控和跟踪，性能分析，实时告警。这些都是微服务架构下应用实施上线后最需要的能力。

微服务架构下的监控和运维支撑平台和传统的监控平台有比较大的区别，其一是更加强调类似APM应用性能监控层面的内容，其二是强调服务链监控和跟踪，其三是更加强调监控的实时性和预警能力。同时我们在监控能力植入的时候还需要做到尽量不影响已有功能的性能。