微服务架构系列前序文章：
- 微服务到底改变了什么，你知道吗？：既要低头赶路，又要抬头望天，科技是为人服务的，任何技术背后都有深层次的考量，在此文中我们聊了微服务的本质：一种可以加速分工、促进合作的新协作机制。
- 微服务，为什么可以加速分工、促进合作？：知其然，知其所以然，此文剖析了微服务加速分工、促进合作的技术原理。
- 微服务，为什么从前后端分离开始？：受限于各种客观条件，应用架构从单体式升级至微服务的过程是渐进的，我们需要找到一个好的切入点，而前后端分离是最合适的。
1. 微服务实施包括哪些关键步骤？
从准备引进微服务这套技术栈的想法开始，到一个微服务架构的新系统部署上线，这大概需要经过哪些关键步骤呢？按照相对规范的研发流程来看，我们需要经过下列四个研发阶段：
- 架构设计：依据关键业务场景完成系统的逻辑视图、开发视图、过程视图和物理视图等设计。
- 环境搭建：按照架构设计产出来完成资源的评估和准备，以及环境搭建和网络防火墙的开通。
- 开发测试：细化设计并将设计变成现实，以及通过集成测试、系统测试等确保最终交付质量。
- 发布部署：将构成系统的每个微服务组件打包成特定格式的发布物，并将其部署至环境上面。
微服务的开发测试，跟单体式的应用开发类似，关键区别就是以HTTP RESTful API的形式对外提供服务，测试时要以这些API为切入口，这些API规格就是对外服务的契约，服务之间的合作是以这些契约为基础的。契约，让分工的边界更清晰，让合作更规范。微服务的发布部署主要依赖于容器云和DevOps平台，如果没有这些辅助系统的支撑，那微服务架构的系统是很难运营维护的。
物流配送、电子支付等是电子商务的基础设施，没有这些基础设施的强力支持，电子商务很难取得大的发展，容器云和DevOps平台就是微服务的基础设施，在评估引进微服务架构时，我们需要先看看基础设施是否就绪，否则就事倍功半，即使搭建了完美的微服务架构也很难有好的效果。接下来，我们重点看看架构设计和环境搭建这两个阶段跟单体式应用有什么区别。以前后端分离方案为例，架构设计阶段的主要产出包括下面五类：
- 业务场景：依据业务需求分析出关键的场景，这些场景将会作为架构设计的主要输入和目标。架构设计的质量就主要看设计能否优雅地满足这些业务场景，以及各种非功能性需求等。
- 逻辑视图：按照业务功能定位将系统划分成不同的单元组件，每个组件可以作为一个微服务，对于前后端分离方案来说，整个系统也就分解成前端和后端两个组件。在此基础上，我们还需要根据业务功能来约定前后端组件之间的交互接口，主要包括协议类型（HTTP/HTTPS）、接口规范和关键接口名称等等。
- 过程视图：在设计逻辑视图时我们已经将微服务组件划分好了，相当于角色分工已经确定。接下来我们就要让这些角色来参与关键业务场景的演出了，在过程视图中借助UML时序图将这些角色穿插起来，确定组件之间的调用关系和时序等，并进一步细化接口规格，包括参数、报文等，确保设计可以满足关键场景。
- 开发视图：确定组件的技术栈，采用哪种开发框架搭建项目工程，以及确定源代码的管理方式。通常，JAVA领域以Spring Boot作为开发框架。而源码管理上推荐以逻辑子系统为单位创建代码库，然后为该子系统下面的微服务组件规划独立的子目录。这种方式兼顾业务与技术，因为微服务是技术领域的概念，没有必要将此细节暴露给业务同事，系统和子系统是按照业务划分的，这是业务同事可以理解的。以子系统为单位来申请配置各种类型的资源，包括代码库、软硬件和人力等资源，然后在子系统内部灵活安排，既兼容传统研发流程又满足技术要求。
- 部署视图：不管是逻辑视图，还是过程视图，这些都属于纸上谈兵，最终架构设计的落地实施离不开部署视图。这相当于把每个角色在舞台上的站位确定下来，通过部署视图来衔接逻辑和物理，将其作为环境搭建阶段的重要输入，以便确定资源在不同网络区域的配比，以及不同网络区域连通性等要求。
在环境搭建阶段，资源评估和网络开墙都有些新内容要熟悉的。在单体式架构下，我们主要使用物理机或虚拟机，估算资源使用量相对简单，只需按照生产最小高可用或业务并发访问量来评估物理机或虚拟机的数量与规格（CPU核数、内存大小、存储等）。微服务依赖容器云，除了估算容器的数量与规格外，我们还需要将容器用量转换成物理机或虚拟机的用量，考虑到容器云是在物理机或虚拟机上铺设了一层容器相关的设施，那么物理机或虚拟机的用量不再是容器用量的简单累加，通常还要乘上一个系数（经验值：1.3），以便预留资源用于运行容器云相关的组件等。
资源估算时要满足生产最小高可用和业务并发访问量，其中生产最小高可用是指构成系统的每个组件必须是高可用的，即搭建主从、双活等架构，每个组件至少配备两个实例。在此基础上，我们还要预估业务访问量，每个承担业务流量的组件必须要搭建足够多的实例。除此之外，我们还要按网络区域来分别估算资源，因为不同网络区域需要做物理隔离。在网络开墙环节，我们需要梳理出一个全景图，清楚哪些防火墙必须要开通才能满足业务要求等。
2. 哪些系统适合改造成微服务呢？
微服务属于分布式系统架构，主要是为了应对业务互联网化所带来的海量用户高并发等挑战。从这个角度分析，符合上述场景的系统最具紧迫性改造成微服务架构。也许你负责构建的系统是面向内部用户的，业务稳定，用户量也较小，平时前端变化频次也低，偶尔有些报表类需求，后端也不用过多考虑扩展性、可用性和性能等特性，就眼前看来，你会觉得没有必要采用微服务架构。但从公司、团队和个人的远期发展规划看，不远的将来我们都要掌握微服务架构，用云原生技术栈打造新系统，适应新的云化基础设施，面向全网用户提供创新服务，而当下正是实践新技术的最佳时机。
内部系统不存在太大的业务压力，这样我们就可以更加从容地使用新技术，不需要边开车边换轮胎。当然，在拥抱新技术时步子不能迈得太大，我们可以选择从非核心系统开始微服务化，在这个过程中完成对新技术的熟悉，然后再农村包围城市，逐渐将新技术引入到核心系统当中。所谓的大时代，不过就是一个选择，或去或留？温水煮青蛙，继续开心地使用老技术，还是跳出舒适区拥抱新技术呢？现在我们对微服务的本质有了更进一步的认知，也清楚了微服务架构的演进策略和实施办法，接下来就需要大家撸起袖子动手实践了。
关注「 IT老兵哥 」，赋能程序人生！推荐原创软技能类文章一篇，点击链接查看：程序员，怎样打造个人影响力？
近期热评系列《 程序员必须懂的架构师入门课 》：
