本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
微服务 (Microservices) 是一种软件架构风格 (Software Architecture Style)，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。微服务架构运用于软件架构风格的其中一项概念是甘露运算 (Dew Computing)，意指由许多的小露水 (代表微服务的功能元件) 汇集而成的运算能力。
微服务的起源是由 Peter Rodgers 博士于 2005 年度云端运算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为 Microsoft 下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的存取方式使用，而且复杂的服务背后是使用简单 URI 来开放界面，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。
2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等元件实作。
微服务概念
微服务是一种以业务功能为主的服务设计概念，每一个服务都具有自主运行的业务功能，对外开放不受语言限制的 API (最常用的是 HTTP)，应用程序则是由一个或多个微服务组成。
相对于微服务的是单体式 (Monolithic) 应用程序，单体式应用表示一个应用程序内包含了所有需要的业务功能，并且使用像主从式架构 (Client/Server) 或是多层次架构 (N-tier) 实作，虽然它也是能以分散式应用程序来实作，但是在单体式应用内，每一个业务功能是不可分割的，若要对单体式应用进行扩展时，一定要整个应用程序都放到新的运算资源 (如虚拟机器) 内，但事实上可能应用程序最吃资源或最需要运算资源的只有某个业务部分 (例如跑分析报表或是数学算法分析)，但因为单体式应用无法分割该部分，因此无形中会有大量的资源浪费的现象。
微服务运用了以业务功能的设计概念，应用程序在设计时就能先以业务功能或流程设计先行分割，将各个业务功能都独立实作成一个能自主执行的个体服务，然后再利用相同的协定将所有应用程序需要的服务都组合起来，形成一个应用程序。若需要针对特定业务功能进行扩充时，只要对该业务功能的服务进行扩展就好，不需要整个应用程序都扩展，同时，由于微服务是以业务功能导向的实作，因此不会受到应用程序的干扰，微服务的管理员可以视运算资源的需要来配置微服务到不同的运算资源内，或是布建新的运算资源并将它配置进去。
虽然使用一般的服务器虚拟化技术就能应用于微服务的管理，但容器技术 (Container Technology) 如 Docker 是很适合发展微服务的运算资源管理技术。
微服务架构的特点
-
围绕业务功能进行组织 Organized around Business Capabilities
- 不再是以前的纵向切分, 而改为按业务功能横向划分, 一个微服务最好由一个小团队针对一个业务单元来构建
-
做产品而非做项目 Products not Projects
- 不再是做一个个项目, 交付后就完事了, 而是做产品, 从设计编码到产品运维全过程掌控和负责 you build it, you run it
-
智能终端加简单通道 Smart endpoints and dumb pipes
-
基于resource的API,大量逻辑放在客户端, 服务器端着重于提供资源
Be of the web, not behind the web
-
基于resource的API,大量逻辑放在客户端, 服务器端着重于提供资源
-
去中心化管理 Decentralized Governance
- 自行其是, 自我管理, 不必在局限在一个系统里, 围绕着一个中心
-
去中心化数据管理 Decentralized Data Management
- 各人自扫门前雪, 自己管理和维护自己的数据, 各自之间互不直接访问彼此的数据, 只通过 API 来存取数据
-
基础设施自动化 Infrastructure Automation
- 每个微服务应该关注于自己的业务功能实现, 基础设施应该尽量自动化, 构建自动化,测试自动化, 部署自动化, 监控自动化
-
为应对失败而设计 Design for failure
- 设计之初就要考虑高可靠性High Availablity 和灾难恢复 Disaster Recover, 并考虑在错误监测和错误诊断方面如何着手
-
演进式设计 Evolutionary Design
- 没有完美的架构, 唯一不变的是变化, 要善于应对变化,容易改变其设计和实现, 因为其小,故而易变
微服务架构的特征
-
容易被替换和升级
比如以前用 Ruby 快速开发的原型可以由 Java 实现的微服务代替, 反正服务接口没变, 所以也没有什么影响 -
按功能单元组织服务
职责最好相对独立和完整, 以避免对其他服务过多的依赖和交互 -
微服务可选择最适合自己的技术方案
服务性质的不同影响技术的选型, 比如帐户的注册登录, 完成可以由 ruby on rails, python django 这些脚本框架来实现. 但是, 对于音视频流的编解码和处理, 最好用 C/C++ 甚至汇编语言来写. 其他的诸如数据库的选型, ORM 或 MVC 框架的选择, 都可以随机应变, 按照业务和技术的具体需求, 根据团队的技术栈和人员现状选择最适合的方案 -
架构由层次化转向扁平化
服务内部可以进行适当的分层, 服务之间尽量扁平化, 不要引入过多的层次
微服务架构的风格
-
短小精悍, 独立自治
只做一个业务并专注做好它 -
自动化部署和测试
相比大而全的单个服务, 微服务会有更多的进程, 更多的服务接口, 更多不同的配置, 如果不能将部署和测试自动化, 微服务所带来的好处会大大逊色 -
尽量减少运维的负担
微服务的增多可能会导致运维成本的增加, 监控和故障诊断也可能会更困难, 所以要未雨绸缪, 在一开始的设计阶段, 就要充分考虑到如何及时的发现问题和解决问题 -
拥抱失效与故障
微服务的高可靠性设计和防错性设计是与生俱来的, 分布在不同的机器,地域上的服务的硬件,网络等随时有可能出问题, 而这些问题要对服务质量没有任何影响 -
每个服务都是灵活易变, 可伸缩,可扩展, 可组合的
微服务为应对变化提供了更多的可能, 就象乐高积木, 可以随意增减组合, 堆积出来不同的产品
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！