微服务探索与实践—总述

背景

软件开发是一个不断发展的过程，从当初的面向过程为主到现在的面向对象的开发，软件开发者不断探索与实践更加符合时代发展要求的开发模式与架构思想，而这，也在极大程度上提升了软件开发的效率。

微服务是一种架构模式或者说是架构风格，而架构这个词语，相信有不少人都曾试图为它作出明确的定义，但是很难下，由于软件架构也在不断发展，内涵也在不断获得丰富。只是不变的是，咱们须要经过软件架构，根据族组织、业务、技术等因素划分出不一样的但能够相互协做的应用系统，使得设计出来的系统具备较高的伸缩性、可维护性以及可扩展性。

三层架构

曾经在与朋友讨论微服务的时候，朋友曾经说过三层架构是否是能够避免在某种程度上因架构设计带来的耦合度过大问题，我跟他说应该很难，由于三层就架构更多的关注是统一系统内的职责划分问题，而架构更多的是关注多套系统。这里的话，顺便提一下三层架构，你们对这种架构应该不会陌生，它主要包括表示层、业务逻辑层以及数据访问层，以下图所示

能够发现，三层架构方式使得各层的关注点更加清晰，但若是随着业务的扩大，三层架构只是延长了系统的生命周期，并不会对系统架构带来太大的改变。这就须要讨论单体系统带来的问题了。

单体系统

三层架构是一种经典的单体应用架构。单体系统有的特色就是，开发、测试、部署都比较简单，之前我所在的公司，由于性能问题，几乎须要花大力气重构系统的时候，却发现只须要再加几台服务器就能够很简单的解决这个问题了，这说明了系统的水平扩张也很是简单。但即使他这么简单，如今也已经再也不推荐去作了。

单体系统意味着公司全部的业务逻辑都被整合进去了，想要一个新人快速上手几乎不太可能，同时老员工离职所带来的风险也是不可估量的。随着大量功能的集成，也对将来新需求的继续集成带来了很大的困难，牵一发而动全身，实在让人迫不得已。更重要的是，互联网的快速发展，要求咱们要作到快速开发、快速集成、快速上线、快速迭代，而单体应用很难作到这点，由于不少团队都会要求对系统的核心功能进行回归。

因此从架构角度对系统进行拆分就成了一种必要，SOA也随之诞生，本文不会具体讨论SOA，只会简单说明一下SOA关于系统拆分的理念。SOA是一种粗粒度、松耦合服务架构，服务之间经过简单、精肯定义接口进行通信，不涉及底层编程接口和通信模型。相对而言，SOA对系统拆分的力度彷佛没有太“微”，可是和微服务思想几乎没有什么太大的区别了。

微服务与SOA

微服务与SOA的区别（因为不少场景下，SOA会使用到ESB，放在这里也方便与微服务作更好的比较，多说一句，ESB逐渐被P2P的虚拟总线所替代），以下图所示

经过上图，能够知道微服务与SOA最大的区别在于，SOA使用了ESB来集成基于不一样协议的服务之间的交互工做，而微服务去除了中间的管道，以服务化方式进行交互和集成。

	SOA	微服务架构
关注点	关注可重用性的最大化，但服务粒度较大	完全实现服务器的组件化，服务粒度较小，并关注“上下文边界”
通讯协议	（一般会经过ESB调度）支持多种消息协议	使用轻量级协议，推荐使用REST full风格，如HTTP
开发与交付	修改时，因为依赖较大，每每牵扯面很大，交付并不灵活	能够只是基于一套服务，交付快捷灵活
数据存储	可共享数据存储	每一个微服务拥有独立的数据存储
部署	使用通用平台	能够不基于通用平台
服务治理	共同的治理和标准	服务微治理，实时生效
趋势	DevOps、持续交付、容器，作的并非很好	DevOps、持续交付、容器在微服务方面的实践很是的丰富

总的来讲，微服务是SOA的一个子集或者是升级版，它是SOA在互联网时代发展的必然进化结果，它有力的促进了企业级系统服务架构的实践。

微服务特性

前面有讲过，微服务是一种架构风格，一个大型应用系统有一个或多个微服务组成，系统中的各个微服务可被独立部署，各个微服务之间是松耦合的，每一个微服务体现着单一职责原则。它主要有如下特性:

• 完全的组件化
  • 完全的组件化有着极好的灵活性和可替换性，明确了单一职责，它能够在不影响或者极少影响其余业务组件的状况下进行快速迭代与快速交付，也实现了业务的高度内聚
• 技术的异构性
  • 在微服务架构中能够根据不一样的业务特征采用不一样的技术方向，有针对性的解决具体的业务问题
• 独立存储与部署
  • 每一个微服务拥有本身的数据库，并部署在不一样的平台上
• 围绕业务组建团队
  • 不一样于传统的IT团队，对技能以及职责的区分很是明确，在微服务里，提供以业务为核心，按业务能力组建团队，所以团队成员的技能是跨领域的一体化团队，一般团队不会太大。

写到最后

微服务确实有着无可比拟的优点，可是微服务也带来了很大的缺点：

• 加大分布式系统的复杂度：随着服务的拆分，原先基于进程内通信的功能被迁移到了进程间通讯或者网络通讯，增长了不稳定性；也会存在服务版本的变化必须兼容其余服务的问题，从而致使接口版本过多，存有大量的重复代码
• 测试压力与运维成本：原先的一个系统被拆分出了不少套微服务，这些都须要增长测试与运维的投入
• 服务治理与监控也很是复杂，须要有人力的投入

因此，微服务的进行，须要根据现状在作决定，切不可为了拆分而拆分