【Springcloud】第一篇 十分钟了解微服务

一、为什么会出现微服务

（一）单体架构的缺点

1. 项目过于臃肿
所有的功能模块都集中在同一个项目的时候，整个项目就会变得特别臃肿，开发者维护起来就会特别困难，增加维护成本。
2. 资源无法隔离
整个单体系统的各个模块都依赖于同样的数据库和内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。可能因为某个模块的一个小问题导致整个系统都不能用了，改完也需要将整个项目重新部署
3. 无法灵活扩展
当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，即部署在多态机器上组成集群，但是这种扩展并非灵活的扩展。可能我们现在的性能瓶颈只是某个模块（例如下图支付模块），所以我们只希望对该模块进行水平扩展，但是单体系统无法做到这一点。

（二）微服务的优势

1. 独立部署，灵活扩展
在传统的单体系统中我们部署的单位是整个系统，而微服务则是以每一个独立的服务单元（独立组件）为单位进行部署。这是我们就可以根据不同服务的吞吐量的不同来部署不同数量的服务器。

2. 资源的有效隔离
微服务的设计原则之一就是每一个服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。如果每个微服务实例在docker容易上运行的话，还可以实现服务器资源（内存、CPU资源等）的有效隔离。
3. 团队组织架构的调整
微服务设计的思想也改变了原有企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DNA的团队，测试有测试的团队。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是 一个团队来负责，支付业务是一个团队来负责。（这种垂直划分只是一个理想的架构，并不是每个公司和企业都符合这样的条件把团队组织架构拆分的这么绝对）。

二、什么是微服务

微服务的理念是由国际种著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家Martin Fowler提出的。
Martin Fowler论文网址
就目前而言，对于微服务业界并没有一个统一的标准的定义。通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，但每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储技术。

三、微服务的优缺点

（一）优点

1. 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求 开发简单、开发效率高，一个服务可能就是专一的只干一件事
2. 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成
3. 微服务是松耦合的，是有功能有意义的服务，无论是在开发阶段还是部署阶段都是独立的 微服务能使用不同的语言开发
4. 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins、Hudson、bamboo
5. 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更加关注自己的工作成果，无需通过合作才能体现价值 微服务允许你利用融合最新技术
6. 微服务只是业务逻辑的代码，不会和HTML、CSS或其他界面组件混合
7. 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

（二）缺点

1. 开发人员要处理分布式系统的复杂性
2. 多服务运维难度，随着服务的增加，运维的压力也在增大
3. 系统部署依赖
4. 服务间通信成本
5. 数据一致性
6. 系统集成测试
7. 性能监控

四、微服务的技术栈

微服务条目	落地技术
服务开发	Springboot、Spring、SpringMVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用(客户端调用服务的简化工具)	Feign等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloudConfig、Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Spectator等
全链路追踪	Zipkin，Brave、Dapper等
服务部署	Docker、OpenStack、Kubernetes等
数据流操作开发包	SpringCloud Stream（封装与Redis,Rabbit、Kafka等发送接收消息）
事件消息总线	Spring Cloud Bus
…	…

五、微服务和SOA

（一）SOA

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能 单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它已经独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA架构是一种粗粒度、松耦合的服务架构，更多的强调异构系统之间的服务通信和解耦合。

（二）微服务

微服务是系统按业务边界做细粒度的拆分和部署。我们需要清楚地是微服务并非指他的体积足够小而是它的职责足够单一。很多人误以为“微”服务拆分的足够小就是微服务，然而并不是这样。“微”还有微不足道的意思，也就是说某个服务出现故障，它不会影响整个系统。微服务是面向服务架构发展的下一步。基本上这种架构类型是开发软件，web或移动应用程序作为独立服务套件的一种特殊方式。创建这些服务仅用于一个特定的业务功能。他们之间完全相互独立，这意味着他们可以用不同的编程语言并使用不同的数据库，集中式服务管理几乎不存在，微服务使用轻量级HTTP，REST或Thrift API互相进行通信。

（三）对比

微服务不再强调传统SOA架构里面比较中的ESB总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化，微服务是SOA的一种轻量级的解决方案，其本质还是SOA，只是更容易落地实现而已。微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端webui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉的团队
管理	着重中央管理	着重分散管理
目标	确保应用能够相互交互	执行新功能，快速拓展开发团队

六、微服务的适用场景

1. 需要对系统细粒度监控

2. 经典架构模式太重

3. 提升系统可用性，如果一个系统挂了，不会对整个业务产生致命影响

4. 应用变得越来越大

5. 修改一个bug需要平滑升级

6. 项目存在多种开发语言

七、微服务框架的对比

参考文献：
什么是微服务
SOA与微服务是什么？之间有什么联系？