微服务架构设计实践系列之二：微服务
2 微服务
css
2.1 微服务的定义html
微服务是一个独立、可部署的服务，它只专一作一件事情而且作好，而这个事情一般能够是业务能力，或者提供业务价值的最小单元服务。数据库
微服务的描述具备通常服务描述所遵循的内容：微信
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.部署基于微服务的应用也要复杂得多。微服务由不一样的大量服务构成，每种服务拥有本身的配置、应用实例数量以及基础服务地址，这里就须要不一样的配置、部署、扩展和监控组件。此外，咱们还须要服务发现机制，以便服务能够发现与其通讯的其余服务的地址。所以，成功部署微服务应用须要开发人员有更好地部署策略和高度自动化的水平。
基于上述的微服务存在的优缺点，以及微服务架构设计过程当中面临的挑战，建议在软件架构设计时，不要从一开始就以微服务架构做为系统设计的起点。相反地，要用一个单个系统做为起点，并保持其模块化。当这个系统出现了问题后，再将其分解为微服务。
微信扫一扫，关注该公众号
该系列文章已经在微信公众号发布，若是感兴趣，请关注。
之后更多知识经过该微信公众号分享。
