一、微服务介绍

1.1 什么是微服务

   “微服务”最初是由 MartinFowler 在 2014年写的一篇文章 《MicroServices》中提出来的。 关于 Martin Fowler 的介绍，维基百科上是这样描述的:

Martin Fowler，软件工程师，也是一个软件开发方面的著作者和国际知名演说家，专注于丽向对象分析与设 计、统一建模语言、领域建模，以及敏捷软件开发方法，包括极限编程。 主要著作有 〈可重用对象模型 〉〈重构一一改 善既有代码的设计 〉〈企业应用架构模式 〉〈规划极限编程 〉 等。(--摘自网络 )

  对于微服务，业界没有一个严格统一的定义，但是作为“微服务”这一名词的发明人，MartinFowler 对微服务的定义似乎更具有权威性和指导意义 。 他的理解如下:

简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻 量级机制通信，通常是 HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来 独立部署。 这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。

特点总结为以下内容：

• 按业务划分为一个独立运行的程序，即服务单元.
• 服务之间通过 HTTP 协议相互通信。
• 服务集中化管理。
• 自动化部署。
• 可以用不同的编程语言。
• 可以用不同的存储技术。
• 微服务是一个分布式系统。

1.2 微服务的优缺点

1.2.1 优点

• 将复杂业务拆分为简单业务，每个业务对应一个服务，将问题简单化。
• 采用分布式系统，高度解耦，提高扩张性；支持集群化部署，提高系统的负载能力。
• 服务之间的通信支持HTTP，MQ以及RPC等多种通信方式，无需考虑技术和语言的限制。
• 微服务的每个服务单元都是独立部署的，每个服务的维护互不影响，便于部署和运维。
• 微服务具有高可用性和分区容错性，高可用性体现在可以提供不间断的服务，集群化部署，负责能力强；分区容错性则使得系统更加健壮。

1.2.2 缺点

• 构建微服务系统相对单体系统比较复杂，服务之间的依赖性较高，服务的修改造成的影响较大。
• 由于服务之间需要跨进程调用，所以保证事务一致性是一个难题。
• DevOps要求，随着服务的增多，需要更高的自动化部署能力。
• 服务数量增加，测试工作相对复杂。
• 系统复杂，当服务数量增加，管理复杂性增加。
• 运维开销大，更多的服务意味着更多的运维。

1.3 微服务的设计原则

  对于软件设计来说，软件设计每一个版本都在变化，所以软件设计应该是渐进式发展 。软件从一开始就不应该 被设计成微服务架构，微服务架构固然有优势，但是它需要更多的资源，包括服务器资源、技术人员等。追求大公司所带来的技术解决方案，刻意地追求某个新技术，企图使用技术解决所有的问题，这些都是软件设计的误区。
  技术应该是随着业务的发展而发展的，任何脱离业务的技术是不能产生价值的 。在初创公司，业务很单一时，如果在单体构架够用的情况下，就应该用单体构架，因为它开发速度快，性价比高。随着业务的发展，用户量的增加 ，可以考虑将数据库读写分离、加缓存 、加复杂均衡服务器、将应用程序集群化部署等。如果业务还在不断发展 ，这时可以考虑使用分布 式系统，例如微服务架构的系统。不管使用什么样的架构，驱动架构的发展一定是业务的发展， 只有当前架构不再适合当前业务的发展，才考虑更换架构。
  在微服务架构中，有三大难题，那就是服务故障的传播性、服务的划分和分布式事务。在微服务设计时， 一定要考虑清楚这三个难题，从而选择合适的框架。目前比较流行的微服务框 架有 Spring社区的SpringCloud、Google公司的 Kubemetes等。不管使用哪一种框架或者工具， 都需要考虑这三大难题 。为了解决服务故障的传播性，一般的微服务框架都有熔断机制组件。 另外，服务的划分没有具体的划分方法，一般来说根据业务来划分服务 ，领域驱动设计具有指 导作用 。最后，分布式事务一般的解决办法就是两阶段提交或者三阶段提交，不管使用哪一种都存在事务失败，导致数据不一致的情况，关键时刻还得人工去恢复数据。总之 ，微服务的设计一定是渐进式的，并且是随着业务的发展而发展的。