微服务是什么？

微服务

目前从事云的相关业务开发，总是会接触到大量微服务的概念。模模糊糊，好像知道是什么，但又好像什么都不知道。
迷迷糊糊而是不好的，借助网上的一些材料，鄙人好好地学习一下微服务的概念吧。

以下资料大部分来自互联网，结尾处会标有引用来历。

单体应用

在微服务概念出现之前，普通的应用程序将所有的功能都包装在一起的，这样的B/S应用架构如图所示：

然而，当用户访问量增大到一定程度后，单服务已经无法支撑时，便需要添加新的服务器并增加负载均衡：

后来，将静态文件独立出来，并通过CDN等手段进行加速，提高了应用的整体响应，因此应用架构又变成了如下形式：

CDN，全称为Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
一般来说，CDN有如下特点：

1. 节省骨干网贷款，减少带宽需求量；
2. 提供服务器端加速，解决由于用户访问量大造成的服务器过载问题；
3. 服务商能使用Web Cache技术在本地缓存用户访问过的Web页面和对象，实现相同对象的访问无须占用主干的出口带宽，并提高用户访问因特网页面的相应时间的需求；
4. 能克服网站分布不均的问题，并且能降低网站自身建设和维护成本；
5. 降低“通信风暴”的影响，提高网络访问的稳定性。

上述三种架构中，都还仅仅是单体应用，只是在部署层面进行了优化，无法避免单体应用的根本缺点：

1. 代码臃肿，应用启动时间长。
2. 回归测试周期长，修复一个bug可能需要对所有关键业务都进行回归测试。
3. 应用容错性差，某个小功能的程序错误都可能导致整个系统的宕机。
4. 伸缩困难，单体应用拓展性能时只能整个应用进行拓展，造成计算资源的浪费。
5. 开发协作困难，一个应用可能需要几十上百人进行开发。

微服务

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。

微服务架构使应用程序更易扩展、更快开发，从而加速创新并缩短新功能的上线时间
。
整体式架构与微服务架构
通过整体式架构，所有的进程紧密耦合，并且作为单项服务运行。
这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。

使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。
这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。

微服务的特性

自主性

可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。

专用性

每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。

微服务的优势

敏捷性

微服务促进若干小型独立团队形成一个组织，这些团队负责自己的服务。各团队在小型且易于理解的环境中行事，并且可以更独立、更快速地工作。这缩短了开发周期时间。您可以从组织的总吞吐量中显著获益。

灵活扩展

通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。

轻松部署

微服务支持持续集成和持续交付，可以轻松尝试新想法，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。

技术自由

微服务架构不遵循“一刀切”的方法。团队可以自由选择最佳工具来解决他们的具体问题。因此，构建微服务的团队可以为每项作业选择最佳工具。

可重复使用的代码

将软件划分为小型且明确定义的模块，让团队可以将功能用于多种目的。专为某项功能编写的服务可以用作另一项功能的构建块。这样应用程序就可以自行引导，因为开发人员可以创建新功能，而无需从头开始编写代码。

弹性

服务独立性增加了应用程序应对故障的弹性。在整体式架构中，如果一个组件出现故障，可能导致整个应用程序无法运行。通过微服务，应用程序可以通过降低功能而不导致整个应用程序崩溃来处理总体服务故障。

微服务的缺陷与解决办法

服务注册与发现

微服务之间相互调用完成整体业务功能，如何在众多微服务中找到正确的目标服务地址，这就是所谓的服务发现。

常用的做法是服务提供方启动的时候把自己的地址上报给服务注册中心，这就是服务注册。服务调用方调用服务变更通知，动态的接收服务注册中心推送的服务地址列表，以后想找哪个服务直接发送给它即可。

服务监控

单体程序的监控运维还好，大型微服务架构的服务运维则是一大挑战。服务运维人员需要实时地掌控服务运行中的各种状态，最好有个控制面板能够看到服务的种种内存使用率、调用次数、健康状态等信息。

这就需要我们拥有一套完备的服务监控体系，包括拓扑关系、监控、日志监控、调用追踪、告警通知、健康检查等，进而做到防患于未然。

服务容错

任何服务都不能保证一直不出问题，生产环境复杂多变，服务运行过程中不可避免地出现各种故障（宕机、过载等等），工程师能够做的就是在故障发生时尽可能地降低影响范围、尽快恢复正常服务。

为了达成这一点，就需要引入“熔断、隔离、限流、降级、超时机制”来为服务容错机制保证连续可用性。

服务安全

有一些服务的敏感数据存在安全问题，服务安全就是对敏感服务采取安全鉴权机制，对服务的访问进行相应的身份验证与授权，降低数据泄露的风险。

安全是一个长久的话题，在微服务之中也有需要多工作有待研究和完成。

小结

简单来说，微服务的概念是面向单体应用的，是如今云业务相关的主要项目模式，很多业务可能会有上百个微服务来共同支撑，其中值得学习的内容还有很多很多，这里记录的只是一些概念性的内容罢了。

参考资料
微服务入门这一篇就够了
什么是微服务-AWS
微服务架构是什么