微服务作为一项可以在云平台上部署应用和服务的新技术已成为当下的热门话题，本文我将根据自身的工作经历，来给大家阐述什么是微服务，以及微服务的特点，希望大家在以后构建微服务体系或对原有系统升级中有所帮助。
1
单体架构
说到微服务不得不说单体的应用架构，我的第一份工作是预付费智能表系统开发工作，那个时候工作基本由一个人或者几个人完成，没有太大的规模，一个人基本完成了如编译后分发、配置、部署、发布等工作，那个时候采用服务端应用程序是几个独立的几兆的文件，有B/S结构和C/S结构的，可以部署在windows硬件服务器上。这种应用程序通常被称为单体应用，单体应用的架构方法论，就是单体应用架构(Monolithic Architecture)。单体应用架构下，一个服务中包含了与用户交互的部分、业务逻辑处理层和数据访问层。如果存在数据库交互则与数据库直连，如下图所示。
在单体应用架构下，一个服务中，两个业务模块作为该服务的一部分存在同一进程中，它们通过方法调用的方式进行通信，如下图所示。
通过在单体应用架构下，不同阶段的服务端相关工作，可以感知到单体应用的特性。
//1.日常研发测试阶段
a) 编译：完整编译一次需要 10 到 60 分钟不等，所以一般会控制编译次数，如晚上和午休各一次；
b) 分发：编译完成后，通过内网，或者目录共享的发方式，分发给不同的小组，一般是研发和测试人员；
c) 部署：内网部署较简单，先将服务端文件复制到服务器本地目录，关闭运行中的服务器程序，将新服务器文件覆盖至运行目录，再启动服务器程序即可。
//2.对外发布阶段
系统在对外发布时的操作与内网类似，但每一步会比内网更加严格。如果通过远程部署，受制于公网速度和线上运行的服务器个数，更新服务器需要几个小时，且更新期间服务不可用，因此每次发布计划需要花费研发和测试团队的大量时间。为了确保应用程序不会由于新发布的功能而中断服务，研发团队会根据客户的使用情况，尽可能减少更新的频次，比如两周左右停服更新一次，通常在晚上更新，避免影响用户业务，除非有特别严重的 Bug 需要修复。
//3.线上运维阶段
因为所有的功能集中在少数的几个服务端文件中，一个 Bug 可能导致某个服务端文件产生崩溃，进而影响服务的使用。在线上运维过程中如果出现性能瓶颈，也不能单独对热点模块进行扩容，只好针对该热点模块所在的服务端文件进行整体的扩容。
//4.其他阶段
服务端的技术栈是在立项时的技术调研阶段，经过慎重评估后选定的。它是一种平衡的技术栈，可以很好地满足所有需求，因此每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
另外，随着时间的推移、需求的变更和技术人员的更替，服务应用中会形成许多技术债务。因为我完整经历了那个项目，期间经历了多次大规模的“重构”，每次重构对整个项目的人员来说都是“灾难”，但又不得不进行。由于只有几个单独的可执行文件，所以项目文件包含了太多模块，这也使得整个项目非常复杂，每次修改代码就需要非常小心，因为太容易引入新的 Bug 了。
现在应用程序日益复杂化，项目对于迭代速度的要求也越来越高，上述的不足会暴露得更加明显，在这种时代背景下，微服务架构开始在企业生根发芽。
2
微服务架构下的服务特性
后来我转到了互联网公司工作，所在项目的服务架构与过去经历过的单体应用架构下的服务差异巨大。同等规模的研发团队，服务的个数竟然有数十个，虽然数量众多，但每个服务都只负责同类的业务功能，能独立地部署到环境中，服务间边界相对清晰，相互间通过轻量级的接口调用或消息队列进行通信，为用户提供最终价值。这样的服务称为微服务(Microservice)。从本质上来说，微服务是一种架构模式，是面向服务型架构(SOA)的一种变体，如下图所示。
上图所示，微服务架构下，业务逻辑层被分拆成不同的微服务，其中不需要与数据库交互的服务将不再与数据库连接，需要与数据库交互的服务则直接与数据库连接。
微服务架构下，因为两个服务分别在自己的进程中，所以它们不能通过方法调用进行通信，而是通过远程调用的方式进行通信，如下图所示。
同样，通过在微服务架构下，不同阶段的服务端相关工作，可以体会微服务的特性。
//1.日常研发测试阶段
因为微服务数量众多，研发和测试团队都有诉求构建一个良好的基础建设。如搭建持续交付工具，通过持续交付工具拉取某微服务代码，再进行编译、分发、部署到测试环境的机器上。再加上，微服务应用程序本身并不大，部署耗时短、影响范围小、风险低，整个编译分发部署的过程在几分钟之内就可以搞定，且几乎是自动完成，因此部署频率可以做到很高。
// 2.对外发布阶段
每次功能的变更或缺陷的修复，在接口不变的情况下，不会影响整个应用的使用。即使某个微服务应用出现缺陷，在事先做好熔断机制的情况下，不会导致整个应用的崩溃，这无疑增加了应用整体的可靠性。再加上部署效率高的特点，一个微服务每天可以发布数次，使得用户能快速感受到新特性和产品价值。
//3.线上运维阶段
在线上运维过程中，如果出现了性能瓶颈，只需对热点服务进行线性扩容。如果某服务的服务器资源利用率不高，可以对其进行线性缩容，这都极大提升了资源利用率。
//4.其他阶段
架构设计方面，微服务可以使用不同的语言，采用不同的架构，部署到不同的环境。同时可以采用适合微服务业务场景的技术，来构建合理的微服务模块。
由此可见，微服务的确解决了单体应用架构下服务的诸多短板。单体应用与微服务对比总结如下。
3
微服务的特点
当然，事物都有两面性，任何一项技术都不可能十全十美，在解决一定问题的同时，也会引入新的问题。 那么，微服务架构下服务有哪些缺点呢？
//1.从微服务架构设计角度来看
•分布式特性：微服务系统通常也是分布式系统，那么在系统容错、网络延迟、分布式事务等方面容易产生各类问题，这也需要投入较多的人力物力去应对。
•技术栈多样性：不同的组件选择不同的技术栈，会导致应用程序设计和体系结构不一致的问题，一定程度上也会产生额外的维护成本。
•Dev-Ops：微服务架构下需要有一个成熟的 DevOps 团队来处理维护基于微服务的应用程序所涉及的复杂性，同时还需要配备相应的工具。
•网络的可靠性：独立运行的微服务使用网络进行交互，这需要可靠且快速的网络连接，同时还需要避免服务间的网络通信存在安全漏洞。
//2.从微服务数量角度来看
• 线上运维方面：更多的服务意味着要投入更多的运维人力和物力，如服务器硬件资源、运行时容器、数据存储和带宽成本、人力维护成本、线上监控成本等。
•团队协作成本：微服务之间主要通过接口进行通信，当修改某一个微服务的接口时，所有用到这个接口的微服务都需要进行调整，当核心接口调整时，工作量更为显著。
•团队沟通成本：为了确保一个团队的服务发生更新时，不会破坏另一个团队的功能，就需要相关团队进行大量的沟通、确认工作。
4
结论
通过对比我们不难看出，微服务架构和单体应用架构的差异及微服务着重解决的用户的痛点，如果当前公司的产品没有单体架构所描述的问题时，我想大可不必升级成微服务架构，并不是所有的场景都适合微服务架构。
