2 微服务
2.1 微服务的定义
微服务是一个独立、可部署的服务，它只专注做一件事情并且做好，而这个事情通常可以是业务能力，或者提供业务价值的最小单元服务。
微服务的描述具有一般服务描述所遵循的内容：
1.使用明确的接口方式，如：WebService、Rest。
2.描述里应该包括约束和策略，如：参数、返回值，以及使用什么通讯协议和数据格式等。
微服务中“微”是其独特个性的体现，“微”表示“接口粒度细”。
简而言之，微服务的特征归结为：
1.职责单一，相对独立。
2.接口粒度细。
3.轻量级通讯协议。
4.服务之间松耦合。
2.2 微服务架构的定义
James Lewis 和 Martin Fowler 给微服务架构的定义如下：
微服务架构风格指将复杂系统切分为几十甚至上百个小服务，每个服务负责实现一个独立的业务逻辑。系统中的各个服务通常是独立部署，彼此之间是松耦合的。
每个服务都运行在自己的进程中，一般采用Rest API风格的轻量级通讯协议进行相互通信。
这些服务围绕业务功能进行构建，通过全自动化的部署方式来进行独立部署。
这些服务可以使用不同的语言来编写，也可以使用不同的数据存储技术，并且基于最低限度的集中管理。
2.3 微服务架构的特征
Martin Fowler 认为，微服务架构具有如下 9 个特性：
1.组件以服务的形式提供。
2.围绕业务功能进行组织。
3.产品而不是项目。
4.强化终端与弱化管道。
5.“去中心化” 地治理技术。
6.“去中心化” 地管理数据。
7.“基础设施” 自动化。
8.“容错” 设计。
9.“演进式” 设计。
2.4 微服务架构的优缺点
微服务架构的优点在于：
1.更加彻底的组件化，系统内部各个组件之间解耦的比较干脆，单个系统的规模小很多。
2.可以组建每个服务独立的维护团队，利于各自团队独立的开发和维护。
3.每个微服务独立部署，只要服务间的接口稳定，各系统可以相互之间互不干扰的独立发展。
4.微服务架构使得每个服务本身可以独立的扩展，性能出现瓶颈，优化或增加这个服务的配置即可。
微服务架构的缺点在于：
1. 微服务强调了服务大小，但实际上，业界并没有给出一个明确的、统一的标准。业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
2. 它的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
微服务架构所面临的挑战：
1.分区的数据库体系和分布式事务。在微服务架构下，不同服务可能拥有不同的数据库。CAP原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
2.对测试带来了很大的挑战。对微服务进行测试，需要启动它依赖的所有其他服务，这种复杂性不可低估。
3.对跨多个服务的更改带来的挑战。在微服务架构中，若有A、B、C三个服务需要更改，A依赖B，B依赖C。此时，我们需要仔细规划和协调每个服务的变更部署，可能需要先更新C，然后更新B，最后更新A。
4.部署基于微服务的应用也要复杂得多。微服务由不同的大量服务构成，每种服务拥有自己的配置、应用实例数量以及基础服务地址，这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
基于上述的微服务存在的优缺点，以及微服务架构设计过程中面临的挑战，建议在软件架构设计时，不要从一开始就以微服务架构作为系统设计的起点。相反地，要用一个单个系统作为起点，并保持其模块化。当这个系统出现了问题后，再将其分解为微服务。
微信扫一扫，关注该公众号
该系列文章已经在微信公众号发布，如果感兴趣，请关注。
以后更多知识通过该微信公众号分享。
