认识微服务

前言

在当今互联网发展中，微服务架构已经流行了很长一段时间了，接下来我们来聊一聊什么是微服务。

微服务的基本概念

---

1、微服务架构的定义

微服务一词源自 马丁·福勒（Martin Fowler) 和 James Lewis共同提出，在2014年3月25日写的一篇博客：Microservices 该文章中对微服务定义如下：

the microservice architectural style [1] is an approach to developing
a single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often an
HTTP resource API. These services are built around business
capabilities and independently deployable by fully automated
deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage technologies.

微服务架构风格是将单体应用程序拆分为多个小型的服务 并且每个服务在独立的进程中。服务间的通信采用轻量级通信的机制 通常是HTTP方式提供API 来实现。这些服务通过自动化部署的方式进行独立部署。每个服务可以根据自身的特点采用不同的语言开发同时也可以使用不同的数据存储技术。

微服务是一种架构风格：没有强制性，没有绝对标准，并不是具体的某一个框架或组件。

Martin Fowler在他的博客中为微服务架构总结了六个特点：

• 一组小的服务

• 独立的进程

• 轻量级通信（通常是HTTP/JSON）

• 基于业务能力（每个服务为独立的业务开发）

• 独立部署

• 无集中式管理（分布式的管理，每个服务可以使用不同的语言，不同的存储技术）

Adrian Cockcroft 更是将微服务比喻成 细粒度的 SOA（面向服务的架构，SOA理念，更细化、更落地）

虽然对微服务的定义进行解释，但是如果想更深层次的了解微服务 我们不得不先从单体架构说起。

---

2、单体架构的定义

一个归档包（例如war格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构。

单体架构好处：

• IDE友好支持：NetBeans、Eclipse、IntelliJ 这样工具专门为单体应用设计。 你只需要使用其中一种 就可以在你本地机器上进行 开发 调试 部署。
• 方便测试：测试人员只需要测试单个应用即可。新开发的功能部署完成就可以测试所有的功能。
• 容易部署：打包成war包放入我们的服务器 或者打包成一个可执行的jar 执行jar包即可。

单体架构缺点：

1. 复杂性高
   以笔者经手的一个百万行级别的单体应用为例，整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐，混乱地堆砌在一起……整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。
2. 技术债务
   随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。
3. 部署频率低
   随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响的范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。
4. 扩展能力受限
   单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，我们不得不在硬件的选择上做出妥协。
5. 阻碍技术创新
   单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和框架，想要引入新的框架或技术平台会非常困难。例如，一个使用Struts 2构建的、100万行代码的单体应用，如果想要换用Spring MVC，切换成本无疑是非常高的。

为了解决以上这些问题，服务化的思想也就应运而生。
  服务化的思想就是将单机应用中的本地方法调用改造为通过RPC接口来进行远程方法调用。以改造调用方式的方法将业务从单体应用中拆分出来，独立成一个服务部署。

---

3、什么是微服务

微服务是服务化思想的进一步演化。与服务化对比微服务有以下几个特点：

1. 服务拆分粒度更细：微服务可以说是更细维度的服务化，小到一个子模块，只要该模块以来的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
2. 服务独立部署：每个微服务都严格遵循独立打包部署的准则，互不影响。
3. 服务独立维护：每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
4. 服务治理能力要求高：因为拆分为微服务之后，服务的数量变多，因此需要有同意的服务治理平台，来对各个服务进行管理。

微服务架构的优点：

1. 每个服务都比较简单，只关注于一个业务功能。
2. 微服务架构方式是松耦合的，可以提供更高的灵活性。
3. 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
4. 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
5. 微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性

微服务架构的缺点：

​ 微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

1. 运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
2. 必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
3. 隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
4. 代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
5. 分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
6. 异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
7. 可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

关于微服务架构的取舍

1. 在合适的项目，合适的团队，采用微服务架构收益会大于成本。
2. 微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
3. 需要避免为了“微服务”而“微服务”。
4. 微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

在了解完之后我们知道微服务只是一种架构方式，我们肯定需要技术架构去实施的，下一篇我们来了解一下微服务的实现方式：SpringCloud

总结

​ 架构选择的优劣只有在系统使用几年后才能真正显现出来，并不是说以前的单体架构就一无是处，通过真确的业务理解，优秀的设计，专业的开发人员。单体应用一样可以支撑业务，同样，对于微服务架构，一个蹩脚的架构设计，一样会导致低劣的产品出来。要知道，微服务各个组件之间的交互是很复杂的，难以管理和控制。