微服务架构 VS 单体服务架构【华为云服务在微服务模式里可以做什么】

针对微服务架构，本文会分为如下几个部分：微服务是个啥？，单体服务架构特点，微服务架构特点，选择微服务要注意什么？，一个完整的微服务系统至少包含了什么？。

微服务是个啥？

最早听到微服务的时候，脑海里最先想到的是“不就是把一个整体服务做小型化”，要做的工作无非就是重构代码，删除冗余，多用继承、多态呗。但去做了调研，就会发现，微服务其实是一种架构模式/风格。

它所提倡的并非是把整体服务做小，而是把整体的服务拆分成一个个小的服务；每个小型的服务可以独立运行在自己的进程中，服务之间互相协调。

微服务这个概念，最早来源于2014年Martin Fowler 的《Microservices》一文中，用来描述“一种将软件应用程序设计为独立部署服务套件的特殊方式”：

“The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. ”

单体服务架构特点

那在微服务架构之前，我们用的最普遍的架构肯定是单体架构（Monolithic Application），一种单体的软件应用程序，在这种应用程序中，用户界面和数据访问的代码都被组合成来自单一平台的单一程序。

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform. A monolithic application is self-contained and independent from other computing applications.

单体服务架构特点：开发集中式管理，简单直接；开发功能全部都在本地，没有分布式方面的管理开销和调用开销。

但同时，单体架构的限制也很明显：

1. 开发效率低：所有开发工作都在在一个项目里进行，研发人员递交代码需要相互等待，代码冲突不断
2. 代码维护难：代码所有功能耦合在一起，新进组的研发人员不知道从何下手
3. 构建时间长：项目里任何小修改都需要重新构建整个项目，每次构建时间都会很长
4. 服务不稳定：一个微小的错误就会导致整个项目崩溃
5. 服务扩展难：服务满足不了高并发场景下的业务需求

因此，随着业务越来越大，场景越来越复杂，对服务敏捷性、灵活性、可扩展性的需求也在不断增长。继续使用单体服务架构带来的会是臃肿的系统、重复的代码、维护运维越来越困难；这时候微服务架构就上场了：单体应用被分解成多个更小的服务，每个小服务单独开发，单独部署，最后组成一个整体的服务。

微服务架构特点

微服务的“微”并非针对代码量，而是说从原先一整个融合了各个业务、功能的范围缩小到了只针对单个业务、功能。

微服务的特点：

1. 松耦合：各个微服务是独立开发，独立部署的，之间是松耦合的状态；单个微服务出现问题不会影响到整个系统
2. 启动快：各个微服务聚焦于自己的业务，代码量变少，依赖变少，启动自然也就变快了
3. 响应快：出现问题，单个微服务定位更快捷，更有利于修复；每次发布新版本，也只需要在整改之后发布对应的服即可，不用整体重新发布
4. 易集成：微服务易于和第三方应用系统集成，各个微服务因为支持使用不同的语言开发，可以选取最利于业务的语言
5. 团队精：每个微服务团队专注于单个业务，团队内成员可以就2-5人，团队做到小而精
6. 易扩容高可靠：因为各个微服务是独立部署的，因此当某个微服务遇到高并发业务场景时，只需将该服务扩容即可（单个微服务可以有多个实例，以此满足负载均衡的需求，提高服务性能和可靠性，以此提高响应速度；单个微服务实例挂了，也有别的实例可以接替其工作，对外表现为某个设备故障后业务依然不中断）

选择微服务要注意什么？

在上面讲述的微服务带来的这么多好处的同时，微服务架构同时也带来了限制：

1. 微服务间调用复杂性高，每个模块因为独立部署，可以直接对外提供服务，之间的通信会带来很多问题比如网络问题，容错问题等；微服务业务上线和下线也是动态，一个统一的服务管理入口就是必须的了（华为云微服务引擎CSE，一款用于微服务应用的云中间件，为用户提供注册发现、服务治理、配置管理等高性能和高韧性的企业级云服务能力，就可以轻松解决这些难题，感兴趣的小伙伴可以点击第三个参考链接~）
2. 微服务架构里，当业务增加时，服务会越来越多，服务的部署、监控也会越来越复杂，会带来更多运维操作和CI/CD的难题（因此DevOps的引入是必要的：技术层面上，DevOps可以促进研发与运维团队的协作；业务上，一致的容器镜像和持续集成/持续部署集成可以更快速地交付客户价值。华为云软件开发平台DevCloud，作为DevSecOps里应用开发和部署的最重要的一部分，在研发需求/规划，开发，测试，发布阶段 助力企业提质增效，感兴趣的小伙伴可以点击第四个参考链接~）
3. 微服务的松耦合会带来分布式事务的挑战，事务一致性难以保障（目前最理想的解决方案就是柔性事务中的最终一致性）
4. 微服务间通信依靠接口来交互，当接口发生改变，对所有的调用方都是有影响的，测试难度变高（如果要靠人工一个个接口去测试工作量就太大了，这时候自动化测试就非常必要了；华为云软件开发平台DevCloud在测试阶段注重测试管理，接口测试，性能测试，帮助企业伙伴做好自动化测试必要的工作）
5. 每个微服务都会有自己的进程，进程本身支持动态的启停，单个微服务也可以有多个实例；但谁来负责什么时候，在哪台设备上启动和停止进程，才是无缝升级的关键（这个就需要背后有一个强大的版本管理、负载均衡、负载监控的系统；华为云云应用引擎CAE，一个面向应用的Serverless托管服务，提供极速部署、极低成本、极简运维的一站式应用托管方案，就支持从源码、软件包、镜像包快速发布应用，秒级弹性伸缩、按量付费，内置负载均衡和监控，感兴趣的小伙伴可以点击第五个参考链接~）
6. 微服务因为独立开发独立部署的特性，一些安全策略问题就是用户不得不面对的比如这么多微服务集中管理策略，如何监控系统状态，服务间依赖关系如何管理，是否可以应付高并发流量情况。（华为云微服务引擎CSE 搭配上 云性能测试服务 CPTS，一项为应用接口、链路提供性能测试的云服务，可以真实还原应用大规模业务访问场景，帮助用户提前识别应用性能问题，感兴趣的小伙伴可以点击第六个参考链接~）

一个完整的微服务系统至少包含了什么？

1. 微服务的注册发现：微服务注册在CSE的微服务中心里，方便别的微服务发现，连接
2. 微服务的服务治理：各服务做好场景化工作；遇到服务崩溃，做好限流/重试/隔离/熔断等措施安全可靠
3. 微服务的配置管理：配置内容秒级下发给微服务，针对微服务做好版本管理服务治理，负债均衡要做好
4. 微服务的安全可靠：异地多活，安全认证，健康检查等
5. 微服务的CI/CD和运维：促进研发与运维团队的协作，需要一致的容器镜像和持续集成/持续部署集成可以更快速地交付客户价值
6. 微服务监控和告警：主要是监控每个服务的运行状态，必要的时候需要产生告警
7. 微服务的日志功能：主要是关于日志的汇总、分类和查询；华为云云日志服务LTS-Log Tank Service提供一站式日志采集、秒级搜索、海量存储、结构化处理、转储和可视化图表等功能，满足应用运维、网络日志可视化分析、等保合规和运营分析等应用场景，感兴趣的小伙伴可以点击第七个参考链接~

参考链接

1. https://martinfowler.com/articles/microservices.html
2. https://en.wikipedia.org/wiki/Monolithic_application
3. https://www.huaweicloud.com/product/cse.html
4. https://www.huaweicloud.com/devcloud/
5. https://www.huaweicloud.com/product/cae.html
6. https://www.huaweicloud.com/product/cpts.html
7. https://www.huaweicloud.com/product/lts.html