多年来，软件行业一直在寻找一种适应于快速发展的网络环境与应用需求的网络架构。这些年来，出现了多种技术、架构模式和一些最佳实践。而微服务是领域驱动设计、持续交付、平台和基础架构自动化、可伸缩系统、多语言编程和持久性领域等软性需求下催生的架构模式之一。



写在前面的话

我们已经介绍了微服务架构是什么，为什么要部署微服务架构以及一些注意点，我想提供最后一条建议：

确定自己真的需要微服务架构吗？确定了后，再去做。



微服务不是灵丹妙药，每一个新节点的引入，都是一个风险点，微服务是牺牲简单性、性能换来的，并不是银弹，我们更多的还是要根据实际场景进行选择。



总之，能用单体服务满足需求的，就先用单体服务吧。



单体应用改为分布式应用，会带来很多新的问题，所以慎重选择吧：

• 网络延时。

• 同步进程间通信导致的可用性降低。

• 在服务之间维持数据的一致性。

• 获取一致的数据视图。

• 上帝类阻碍拆分。



微服务架构是什么？

微服务其实一直都是一个很难从单一角度精确定义的词汇。



Robert C. Martin提出的 单一责任原则 ，其中指出“将因相同原因而发生变化的那些事物聚集在一起，并将因不同原因而发生变化的那些事物分开。”



微服务架构采用相同的思维方式，并将其扩展到可以独立开发、部署和维护的松耦合服务。这些服务中的每一个都负责一块独立的「工作」，并且可以通过简单的API与其他服务通信，以解决更大的复杂业务问题。



微服务架构的主要优势

一个大的服务，会根据服务边界进行拆分成小的服务，因此可以从一开始就由一个或多个小团队构建，这样团队分工更明确，效率更高。



服务与服务之间独立部署，因此更容易针对性的对服务进行扩展。



在一项服务中发生错误的情况下，整个应用程序不一定会整体故障。修复错误后，只需要部署相应的服务，而不必重新部署所有服务。



微服务架构带来的另一个优势是，可以更自由地选择最适合所需功能（服务）的技术栈（编程语言，数据库等），而不是要求采用更标准的技术栈（服务）。



如何开始使用微服务架构？

如何开始？

是否有一套可以遵循的标准设计原则，可以帮助我们更好的落地微服务架构？

答案是：没有。



不过也不用太过悲伤，虽然没有一个标准的设计原则，但通过这么多年的总结（设计模式也是靠大家的智慧这么摸索出来的），微服务架构的设计与开发，还是有很多有迹可循的「方法」的。



如何分解

我们始终要记住一点：企业的价值与存在的意义是其业务能为最终用户提供价值。所以如何正确的基于业务的角度进行服务的拆分，是我们的核心原则，而非技术、语言、框架等技术因素作为指导。



识别业务能力和相应的服务需要对业务有较高的了解。



一旦确定了业务能力，就可以对这些确定的业务能力中的每一个来构建所需的服务。



每个服务可以由不同的团队开发维护，这些团队可以成为该特定领域的业务专家和技术专家，这同样有利于更稳定的API边界和更稳定的团队。



具体的一些方法论：

单一职责原则（SRP：Single responsibility principle）

软件架构和设计的主要目标之一，是确定每个软件元素的职责。单一职责原则如下：

改变一个类应该只有一个理由。 —— Robert C.Martin



类所承载的每一个职责都是对它进行修改的潜在原因。如果一个类承载了多个职责，并且互相之间的修改是独立的，那么这个类就会变得非常不稳定。遵照SRP原则，你所定义的每一个类，都应该只有一个职责，因此也就只有一个理由对它进行修改。



我们再设计微服务时，也应该遵循SRP原则，设计小的、内聚的、仅仅含有单一职责的服务。这回缩小服务的大小并提升它的稳定性。

闭包原则（CCP：The Common Closure Principle）

另一个有用的原则叫闭包原则：

在包中包含的所有类应该是对同类的变化的一个聚合，也就是说，如果对包做出修改，需要调整的类应该都在这个包之内。 —— Robbert C.Martin



这就意味着，由于某些原因，2个类的修改必须耦合先后发生，那么就应该把他们放在同一个包内。也许这些类实现了一些特定的业务规则的不同方面。这样做的目的是当业务规则发生变化时，开发者只需要对一个交付包做出修改，而不是大规模的修改整个应用。采用闭包原则，可以极大的提高程序的可维护性。



在微服务架构下采用CCP，我们就能把根据同样原因进行变化的服务放在一个组件内。这样做可以控制服务数量，当需求发生变化时，变更和部署也更佳容易。理想情况下，一个变更只会影响一个团队和一个服务。CCP是解决「分布式单体」这种可怕的反模式的法宝。



构建和部署

在决定了这些小型服务的服务边界之后，可以由一个或多个小型团队使用最适合的技术来开发它们。例如，使用Java+MySQL构建用户服务，使用Go + Kafka构建弹幕服务。



开发完成后，可以使用Jenkins，TeamCity等CI工具，进行自动测试用例，并将这些服务部署到不同的环境（集成，QA，灰度，生产等。

设计服务

在服务设计阶段，需要认真考​​虑将要对外暴露的能力、使用什么协议与外部进行交互等。



对服务的复杂性和实现细节对外部客户端进行屏蔽非常重要。如果暴露了不必要的细节，那么以后很难更改服务。



遵循“少即是多”的原则，尽量少的暴露内部细节，只提供紧凑的API给外部使用。



下图显示了设计微服务时的常见错误之一：



如图中所示，把Service 1的信息存储到数据库中。当创建另一个需要相同数据的服务Service 2时，直接从数据库(DB)访问该数据。



在某些情况下，此方法似乎合理且合乎逻辑-可能很容易访问SQL数据库中的数据或将数据写入SQL数据库。



但是，这种方式违反了我们上面提到的对复杂性与细节的隐藏。如果以后我们需要更改架构，比如修改数据库MySQL为TiDB, 就会发生很严重的问题，因为我们不知道谁在使用数据库，也不知道更改是否会影响其他服务（Service 2）的运行。



下面是一种替代方法：

Service 2通过Service 1 的API获取需要的数据，避免直连数据库，这种架构更改保留了更大的灵活性（解耦），只需要保证API契约不变，Service 1的内部变更就不会影响Service 2的使用。



还有就是请谨慎选择服务之间的通信协议，例如：如果选择了Java RMI，导致的问题就是API的调用者仅限于JVM系语言，而且很难保证其前后兼容。

部署

混布微服务

首先，每台机器可以部署多个微服务。在自建机房的场景下，有利于节省成本。



但这种方法限制了独立更改和扩展服务的能力。这也给管理依赖关系带来了困难。例如，如果使用Java编写，则同一主机上的所有服务都必须使用相同版本的Java。此外，独立服务之间可能会产生负面的互相影响。

单机部署

一般情况下我们首选每个机器部署一个微服务。



而且现在云服务器占据主流，但ESC部署一个微服务，对应成本也不会很高。

版本升级

微服务面临的另一个问题就是，当其他服务正在生产环境使用它时，如何对其进行进行升级，需要保证依赖它的微服务正常的执行调用。



有多种解决此问题的方法。



对API进行版本控制，并在需要对API进行更改时，在仍保持第一个版本不变的情况下部署API的新版本。然后推送依赖服务升级使用较新的版本。一旦将所有依赖服务迁移为新版本API后，再将历史版本进行关闭清理。



实践告诉我，这是一个有点糟糕的方法，维护各种版本很困难，任何新的更改或错误修复都必须在两个版本中进行。



因此，可以考虑一种替代方法，其中当需要更改时，在同一服务中实现另一个接口。一旦新接口被所有服务使用，则可以删除旧的接口。



这种方法的优势在于，由于始终仅运行一个API版本，因此维护服务更加容易。

制定标准

当有多个团队分别负责不同的服务时，最好引入一些标准和最佳实践，例如错误处理。没有约定的话服务可能会以不同的方式处理错误，编写大量不必要的代码。



服务依赖

微服务体系中，随着服务的增长，服务实例的数量及其位置（主机+端口）可能会动态变化。同样，共享数据的协议和格式可能因服务而异。

API网关和服务发现就能带来很大的帮助，使用API网关成为所有客户端的单一入口点，并且API网关可以为每个客户端公开不同的API。

API网关还可以实现安全策略，例如验证客户端是否有权限执行请求。

异常失败

需要了解的重要一点是，默认情况下微服务不是弹性的。服务将会失败。由于相关服务的故障，可能会发生故障。此外，由于各种原因（例如代码中的错误，网络超时等），也会导致失败。

微服务架构的关键是需要确保部分出错时，整个系统不会受到影响或崩溃。



所以服务降级、限流等操作是很有必要的。



监视和记录

微服务本质上是分布式的，服务的监视和日志记录是一个挑战。排查问题时，我们很难遍历每个服务实例的日志并将它们关联起来。



为了解决这些问题，一种方法是利用集中式日志记录服务，该服务将来自每个服务实例的日志聚合在一起。用户可以从一个集中位置搜索这些日志，配置报警规则，在出现某些消息时配置警报。

提供了标准工具，并已被各种企业广泛使用。ELK Stack是最常用的解决方案，其中日志记录守护程序Logstash收集并聚合日志，可以通过由Elasticsearch索引的Kibana进行搜索。



也可以使用一些分布式日志之类的方案，现在有很多工具可以实现分布式系统监控。