章
目
录
一、什么是微服务？
一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。——摘自维基百科
以上的定义可能有些晦涩难懂，简单地讲就是：微服务是一种体系结构样式，将单个应用程序划分为较小的服务单元，并在微服务之间使用HTTP的API进行资源访问和操作。这些服务仅用于某一个特定的业务功能，例如：用户管理、用户角色、电子商务购物车、搜索引擎、社交媒体登录等。此外，它们是相互独立的，这意味着它们可以采用不同的编程语言和数据存储。
如果你还不了解什么是SOA以及为什么要使用微服务可以详细看下潘老师之前写的一篇文章：
Java开发网站架构演变过程，到目前为止，大致分为5个阶段，分别为单体架构、集群架构、分布式架构、SOA架构和 […]
二、微服务架构优点
1）服务的独立部署
每个服务都是独立项目，可以独立放置，不依赖其他服务，并且联接器很低。
2)服务快速入门
分割后服务启动速度必须比分割前快得多。因为依赖的库少，代码量少。
3)更适合敏捷开发
敏捷开发以用户的需求进化为核心，以迭代、渐进的方法进行。服务分割可以快速发布新版本，您只需发布该服务，而不必完全重新发布要修改的服务。
4)全权负责，专责小组负责专门服务
随着业务的快速发展，研发人员也在增加，每个团队可以负责各自的业务线，服务划分有助于团队之间的分工。
5)服务可以根据需要动态扩展
当对某项服务的访问量很大时，只需扩大这项服务。
6)重复使用代码
每个服务都提供REST API，需要提取所有基本服务，许多基本实现作为界面提供。
三、微服务架构缺点
1）团队沟通的过载：
微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题，但是微服务架构的应用这个问题会更加明显。
2）正式文档的过载：
每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。
3）不一致性的应用：
我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。
4）DevOps的复杂度：
我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。由于多个应用存在多个活动部件，这种复杂度需要有高水平的经验。
5）增加了资源使用：
运行这些微服务架构的应用的初始投资会比较大，因为所有微服务应都需要拥有他们自己的运行容器，这也需要更多的CPU和内存。另外采用了中间件也会带啦一个比较大的基座投资。
6）增加了网络通信开销：
分布式系统的产生的网络开销比单机应用多很多，不能简单把内部调用简单改为分布式调用，吃亏很大。微服务架构下，独立运行的组件都需要通过网络进行互相通信。这中系统需要有更加可靠和快速的网络连接。
7）编码和解码：
这个容易理解，也会产生性能问题。
8）网络安全：
通过网络进行通信的系统更容易产生安全缺陷。
9）测试：
测试微服务架构的应用绝对比单体应用难很多，深有体会，集成测试过程是一场噩梦。
10）产品监控：
监控微服务架构应用的成本会更高，很难获得合适的工具，自研的成本也很高。
11）其它：
另外例如方案设计，研发管理，问题排查确实都有不少挑战。
四、微服务架构与单体架构比较
1）单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
2）单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
3）单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。
四、微服务架构与SOA比较
微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。
五、什么样的项目适合微服务
看一个项目适不适合用微服务，主要参考两方面：业务复杂度和性能要求。
1）在业务复杂度较小时采用单体应用（Monolith）的生产率更高。
2）当业务复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化（Microservice）的拆分才是合理的。
1）当并发量比较小的时候，使用微服务并不能体现它的优势。这时用单体结构就可以满足系统的性能要求。
2）当并发量较大时，尤其集中在一个或者少量几个业务场景下，使用微服务便可有效的节省资源。
综上所述，当系统的业务复杂度较小、并发量不高时，使用单体架构较为划算。当业务复杂度较大、并发量较高时则使用微服务架构。但现如今，微服务基本已经成为市场主流。
六、微服务拆分与设计
1）从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节
2）拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。
七、微服务设计原则
1）单一职责原则
意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
2）服务自治原则
意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
3）轻量级通信原则
首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
4）接口明确原则
由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
八、微服务框架
Java中比较流行的微服务框架主要是Spring Cloud和Dubbo：
Spring Cloud是Spring官方提供的微服务一揽子解决方案，为开发人员构建微服务架构提供了完整的解决方案，SpringCloud是若干个框架的集合，它包括spring-cloud-config、spring-cloud-bus等近20个子项目，它提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成。
一个关于Spring Cloud和Dubbo很有意思的比喻，使用Dubbo构建的微服务架构就像组装电脑，各个环节的可选自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，但是如果是一个高手，这一切都不存在问题。Spring Cloud就像品牌机，在Spring Source的整合下，做了大量兼容性的测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外配件时，需要对配件足够的了解。
我们在此主要学习Spring Cloud全家桶，从而进阶微服务！
