本文将为大家介绍什么是Java微服务，了解Java微服务的体系架构，以及如何设计、开发、部署和测试。

Java微服务：基础

要真正理解Java微服务，就必须从最基本的东西开始：为人诟病的Java 大型独体应用，它是什么，它的优点和缺点是什么。

什么是Java 大型独体应用？

假设你正在为一家银行或一家金融科技初创公司工作。你为用户提供一款可以用它来开设新的银行账户的移动应用程序。

如果用Java代码来写，可以实现一个简化版的控制器类，如下所示。

@Controller
class BankController {
    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        riskCheck(form);
        openBankAccount(form);
        // 略……
    }
}

这段代码要：

验证注册表单。
对用户的地址进行风险检查，以决定是否可以给他一个银行帐户。
打开这个银行账户

部署的时候，你会将BankController类与所有其他源代码一起打包到bank.jar或bank.war中：在远古时期，这个庞然大物还是不错的，它包含你的银行系统运行所需的所有代码。（粗略估算，一开始你的jar或war文件的大小会在1-100MB范围之内。）

然后在服务器上运行.jar文件——这就是部署Java应用程序所需要做的全部工作。

Java大型独体应用存在什么问题?

本质上，Java大型独体应用没有什么问题。但通过以往的项目经验，我们可以明显发现，如果你：

让许多不同的程序员/团队/顾问……
面临着高压和不明确需求，围绕同一款大型独体应用工作……
好几年……

那么你那个小小的bank.jar文件就会变成一只巨大的、有千兆字节的代码怪物，每个人都不敢部署它。

如何让Java大型独体应用变得更小？

这自然就引出了如何缩小大型独体应用的问题。现在，你的bank.jar是在一个JVM中运行的，一台服务器上运行一个进程。不多也不少。

现在，你可能会产生一个想法：那个风险检查服务是公司其他部门使用的，我的这款银行应用与它没什么关系，不妨把它切离出去，将它作为自己的产品去部署，作为单独的进程来运行。

什么是Java微服务?

实际上，这意味着你不需要在你的BankController中调用riskCheck()方法，而是将该方法或bean及其所有辅助类移动到它自己的Maven/Gradle项目中，对其进行源代码配置管理，并将其独立部署，不依赖于你的银行系统。

整个提取过程本身会不会使你新的RiskCheck模块成为微服务呢，大家对微服务定义有着不同的解释：

如果它里面只有5-7个类，那么算不算微？
100或者1000个类仍然算是微吗？
这和类的数量有什么关系吗?

我们不去钻理论上的牛角尖，而是关注其实用性，做以下两件事：

调用所有可单独部署的服务（即与大小或领域边界无关的微服务）。
重点关注服务间的通信这一重要主题，因为你的微服务需要相互通信的方式。

所以，总结一下：你之前拥有一个JVM进程，即一个银行大型独体应用。现在，除了这个银行JVM进程，还有一个在自己JVM进程中运行的RiskCheck微服务。你的大型独体应用现在必须调用这个微服务进行风险检查。

怎么做呢?

如何在Java微服务之间进行通信?

基本上，有两种选择：同步通信或异步通信。

(http)/rest（同步通信）

同步微服务通信通常通过HTTP和返回XML或JSON的类似rest的服务来完成——尽管这不是必需的(例如，参考谷歌的协议缓冲区)。

如果你需要立即响应，可以使用REST通信，具体到我们的案例就是这样做的，因为在开户之前必须进行风险检查：不做风险检查，就不给开户。

在工具方面，可以看看哪些类库最适合同步Java REST调用。

消息传递（异步通信）

异步微服务通信通常通过JMS实现和/或AMQP等协议的消息传递来完成。通常，是因为实际上如email/smtp驱动集成的数量是不可低估的。

有时，使用一个微服务并不需要得到立即响应，比如用户按下“立即购买”按钮并希望生成发票，则当然不必在用户购买这一请求/响应周期内完成。

在工具方面，可以看看哪些代理最适合异步Java消息传递。

示例：在Java中调用REST API

假设我们选择使用同步微服务通信，那么我们上面的Java代码看起来就像是更底层的代码。因为对于微服务通信，通常会创建client类库，将实际的HTTP调用抽象出来。

@Controller
class BankController {
    @Autowired
    private HttpClient httpClient;
    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        httpClient.send(riskRequest, responseHandler());
        setupAccount(form);
        // 略......
    }
}

看到这段代码就会发现，现在必须部署两个Java(微)服务：Bank和RiskCheck服务。最终会得到两个jvm，两个进程。之前的关系图看起来将是这样的：

这就是开发一个Java微服务项目所需的全部内容：构建和部署更小的部件(.jar或.war文件)。

但这就留下了一个问题：你究竟如何切分或配置这些微服务？这些小部件是什么？多大合适？

让我们来看看现状。

Java微服务体系结构

实际上，公司可以通过各种方式来设计或架构微服务项目。具体情况取决于你是试图将一个现有的大型独体应用变成一个微服务项目，还是从一个全新的项目开始。

从大型独体应用到微服务

一个更有机的想法是将微服务从现有的整体中分离出来。请注意，这里的“微”实际上并不意味着提取出来的服务本身很小，它们本身可能仍然相当大。

我们来看一些理论。

想法：将一个大型独体应用拆分成微服务

将遗留项目转换为微服务，主要是出于以下三个原因:

它们通常难以维护/变更/扩展。
每个人，都想让事情变得更简单，从开发人员、运维人员到管理人员。
在某种程度上，你对你的领域有着明确的边界界定，也就是说：你知道你的软件应该做什么。

这意味着你可以好好看看你的Java银行应用这个庞然大物，并尝试沿着领域边界拆分它，这不失为一种明智之举。

你可以得出这样的结论：应该有一个“账户管理”微服务，它可以处理用户的姓名、地址、电话号码等数据。
还有前面提到过的“风险模块”，用来检查用户的风险级别，可以供公司的许多其他项目甚至部门使用。
还有一个发票模块，它通过PDF或实际的邮件发送发票。

现实：让别人来做

虽然这种方法在在纸上和uml类图上呈现出来很美，但是它也有缺点。最主要的一点是，使用这种方法需要很强的技术能力。为什么呢?

因为在理解将高度耦合的帐户管理模块从你的大型独体应用中提取出来是个好主意是一回事，正确地去执行它是另一回事，两者之间存在着巨大的差异。

大多数企业项目都到了这样一个阶段，即开发人员不敢将已经用了7年的Hibernate版本升级到新的版本，这只是更新一个类库而已，但也需要做大量工作以确保不会破坏任何东西。

这些开发人员现在要深入挖掘旧的遗留代码（它们没有清晰的数据库事务边界），并提取定义良好的微服务？可能是吧，但通常是真正的挑战，是无法在白板或架构会议上解决的了的。

这是本文中第一次引用推特上@simonbrown的话：

我一直都说……如果你不能正确地构建大型独体应用，那么微服务也帮不了你。
Simon Brown

全新项目的微服务架构

开发全新的Java项目时，情况看起来有点不同。现在，这三点与之前那三点略有不同：

你要从头开始，所以没有要保留的旧包袱。
开发人员希望事情在未来保持简单。
问题：你对领域边界的认识还非常模糊：你不知道你的软件实际上想要做什么（提示：敏捷）。

于是就产生了各种不同的方法，公司可以使用它们尝试处理全新的Java微服务项目。

技术型微服务架构

对于开发人员来说，马上就会想到这样一种方法，尽管我们强烈建议不要使用它。Hadi Hariri在IntelliJ中提出了“提取微服务（Extract Microservice）”重构功能，这一点很是值得称道。

下面的例子做了极度的简化，但实际项目中的情况却与之非常接近。

微服务之前

@Service
class UserService {
    public void register(User user) {
        String email = user.getEmail();
        String username =  email.substring(0, email.indexOf("@"));
        // ...
    }
}

使用了一个substring 的Java微服务

@Service
class UserService {
    @Autowired
    private HttpClient client;
    public void register(User user) {
        String email = user.getEmail();
        // 在这里，通过http调用substring微服务
        String username =  httpClient.send(substringRequest(email), responseHandler());
        // ...
    }
}

于是，你实际上是将一个Java方法调用包装成一个HTTP调用，而这么做并没有特别明显的理由。而一个可能的原因是：缺乏经验而试图强行采用Java微服务方法。
建议：不要这样做。

面向工作流的微服务体系架构

下一个常见的方法是，在工作流之后对Java微服务进行模块化。

举个现实生活中的例子：在德国，当你去看（公共）医生时，他需要在他的健康软件CRM中把你的预约记录下来。

为了让保险报销，他将把你的治疗数据和他所治疗的所有其他患者的数据通过XML发送给仲裁机构。

仲裁机构会看一下那个XML文件并做出处理（已做简化）：

验证该文件是否是正确的XML
验证它的合理性：一个1岁大的孩子每天从妇科医生做三次牙齿清洁，这合理吗？
使用其他一些形式数据对XML加以补充
将XML转发给保险以触发报销
然后向医生反馈结果，其中包括“成功”的消息或“数据有异常，请重新核实修改后再次发送”

现在，如果你尝试使用微服务对这个工作流进行建模，至少会包括以上内容。

注意：在本例中，微服务之间的通信与主题无关，但如果真要提一下的话，可以通过RabbitMQ之类的消息代理异步完成，因为医生不需立即得到反馈。

同样的，从纸面上看，这似乎看起来挺不错的，但我们马上会发现以下几个问题：

你觉得需要部署六个应用程序来处理一个xml文件吗？
这些微服务真的相互独立吗？它们每一个可以独立部署吗？每个都具有不同的版本和API模式？
如果验证微服务停了，那么合理性微服务会做什么？系统还会保持运行吗？
这些微服务现在是否共享同一个的数据库（它们确实需要数据库表中的一些公共数据），或者你是否会采取更大的动作来为它们提供属于自己的数据库?
以及，基础设施或运维方面其他的大量问题。

有趣的是，对于一些架构师来说，上面的图理解起来更简单，因为现在每个服务都有它确切的、定义良好的用途。以前，它看起来像这个可怕的大型独体应用：

虽然这些图画起来简单，但是你肯定需要解决些额外的运维挑战。

你……

不仅需要部署一个应用程序，而是需要至少部署六个。
甚至可能需要部署多个数据库，这取决于你希望微服务体系架构走多远。
必须确保每个系统都保持在线、健康和工作。
必须确保微服务之间的调用实际上是有弹性的（参见如何使Java微服务具有弹性?）
以及这么部署带来的一切差异——从本地开发配置到集成测试。

建议

除非：

你是Netflix（但显示，你不是）……
你拥有超强的运维技能包：你打开开发IDE，就会跳出一只调皮猴，删掉你的生产数据库，你能轻易在5秒内自动恢复。
或者你觉得自己像@monzo，仅仅因为认为自己能行，就尝试了1500个微服务。

否则：

不要这么做。

尽管，没那么夸张。

尝试根据领域边界对微服务建模是一种非常明智的方法。但是，领域边界（比如用户管理和发票）并不意味着拿来一条工作流将其分解为几个最小的部分（接收XML、验证XML、转发XML）。

因此，每当你开始一个新的、领域边界还非常模糊的Java微服务项目时，且领域边界仍然非常模糊，请尽量保持微服务的规模。你总是能够在之后添加更多模块的。

确保在整个团队/公司/部门都拥有非常强大的DevOps技能，以支持你新的基础架构。

多语言或面向团队的微服务架构

还有第三种，几乎是以自由意志主义的方法来开发微服务：让你的团队甚至个人有可能使用他们想用的任何语言或微服务来实现用户故事（行业术语：多语言编程）。

因此，上面的合理性微服务是用Haskell编写的（为了让它看上去更数学），保险的转发微服务应该用Erlang编写（因为它确实需要扩展），而XML验证服务可以用Java编写。

从开发人员的角度来看很有趣的东西（即在一套隔离的环境中使用你的完美语言开发一个完美的系统），基本上不是组织想要的同质化和标准化。

这意味着，应该有一套相对标准化的语言、库和工具，这样即便你不在了，其他开发人员将来也可以继续维护Haskell微服务。

有趣的是，回溯历史可以发现，标准化走得太远了。某些财富500强公司甚至不允许他们的开发人员使用Spring，因为它“不在公司的技术蓝图中”。

建议：

如果你打算使用多语言，请尝试减少同一编程语言生态系统中的多样性。例如：Kotlin和Java（它们都基于JVM，彼此之间100%兼容），而不是Haskell和Java。

Java微服务的部署和测试

请快速回顾一下本文开头提到的基础知识，这对本节会有所帮助。任何服务器端的Java程序，都是.jar或.war文件，因此也包括微服务。

在Java生态系统（更确切地说是JVM）中，有一件事情很棒：只写一次Java代码，基本上就可以在任何你想要的操作系统上运行，只要你用来编译代码的JVM版本不高于运行代码的JVM版本即可。

理解这一点很重要，尤其是涉及到Docker、Kubernetes或云这样的主题时。为什么呢？让我们看看以下几个不同的部署场景：

一个简单的Java微服务部署示例

我们继续以上文的银行系统为例，我们现在有一个monobank.jar文件（那个大型独体应用）和新提取的riskengine.jar（第一个微服务）。

我们假设这两个应用程序与世界上的任何其他应用程序一样，都需要.properties文件，里面保存数据库url和凭证。

因此，最简单的部署可能只包含两个目录，大致如下:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar
ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar
ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

现在，还剩下一个问题：如何将.properties和.jar文件放到服务器上呢？
不幸的是，这个问题的答案可就多喽。

使用构建工具、SSH & Ansible 进行Java微服务部署

对于Java微服务的部署，最无聊但又完美的答案是过去20年中管理员为公司部署Java服务器端程序的方式。它包括：

你最喜欢的构建工具(Maven、Gradle)
古老但好用的SSH/SCP，用于将你的jar包复制到服务器
用于管理部署脚本和服务器的Bash脚本
或者一些更好的：Ansible 脚本。

如果你并不想自动处理所有的负载均衡，随时防备着调皮猴的攻击，时时关注着ZooKeeper的leader选举，那么这种配置就足以应付很长时间了。

陈腐老旧、毫无新意，但的确有效。

如何使用Docker进行Java微服务部署

转回到这个诱人的选择。几年前，出现了Docker和容器化的主题。

如果你以前没有使用过它，那么可以先了解一下它对最终用户或开发人员的意义所在：

容器（简化过的）就像一个古老的虚拟机，但更轻量级。看看这个Stackoverflow上的回答，理解一下轻量级在这个上下文中意味着什么。
容器保证是可移植的，它可以在任何地方运行。这一点是不是有点耳熟？

有趣的是，由于JVM的可移植性和向后兼容性，这个好处听起来好像没那么了不起。你可以在任何服务器、树莓派（甚至是移动电话）上下载一个JVM.zip文件，解压缩后运行任何你想要运行的.jar文件。

但是，对于PHP或Python之类的语言来说，情况就有点不同了，因为这些语言的版本不互相兼容或其部署配置历来都比较复杂。

或者，如果你的Java应用程序依赖于大量其他要安装好的服务（使用正确的版本号）：比如像Postgres之类的数据库或者像Redis之类的键值存储。

所以，Docker对于Java微服务，或者说Java应用程序的主要好处在于：

使用像Testcontainers这样的工具来搭建同质化的测试或集成环境。
使复杂的部署“更容易”。以 Discourse 论坛软件为例。你可以用一个Docker镜像部署它，它包含了你需要的所有东西：从用Ruby编写的Discourse 软件，到Postgres数据库，再到Redis和几乎所有的一切。

如果你想在开发机上运行一个小巧的Oracle数据库，那么试试Docker吧。

所以总结来说，现在不再是简单地scp一个.jar文件，而是：

将jar文件打包成Docker镜像
将该docker镜像传输到一个私有的docker注册表
在目标平台上拉取该镜像，然后运行它
或者，将Docker镜像直接scp到你的生产系统，然后运行它

如何使用Docker Swarm或Kubernetes来部署Java微服务

假设你正在尝试Docker。现在每次部署Java微服务时，你都要创建一个Docker镜像，它绑定了你的.jar文件。你有若干这样的Java微服务，你希望将这些服务部署到若干机器上：即集群。

那么问题来了：如何管理集群，也就是运行Docker容器、执行健康检查、发布更新、扩展，等等等等？

答案可能有两个：Docker Swarm和Kubernetes。

由于篇幅所限，本指南不可能详细介绍它们，但实质上：它们最终都是基于你编写YAML文件来管理你的集群（参见本文“不是问题：YAML缩进的故事”）。如果你想知道在实践中大概怎么做，可以简单在网上搜一搜。

那么，Java微服务的部署过程现在看起来可能是这样的：

安装和管理Docker Swarm/Kubernetes
执行上面所述的Docker 步骤
编写和执行YAML，直到所有的东西都工作正常

如何测试Java微服务

假设你解决了在生产环境中部署微服务的问题，但是在开发过程中如何集成测试微服务呢？如何查看完整的工作流是否工作正常，而不仅仅是单一的局部呢？

在实践中，你会找到三种不同的方法：

做一点点额外的工作（如果你正在使用Spring之类的框架）,你可以把你所有的微服务包装成一个运行器类，使用一个Wrapper.java类来启动所有的微服务，当然，前提是你的机器上有足够的内存来运行所有的微服务。
你可以尝试在本地也安装一套Docker Swarm 或Kubernetes。
不再在本地进行集成测试，而是搭建一套专用的开发/测试环境。很多团队实际上都是这么做的，以避免承受在本地部署微服务之痛。

此外，除了Java微服务之外，你可能还需要一个运行一个消息代理（比如：ActiveMQ或RabbitMQ），或者一个电子邮件服务器或任何其他消息传递组件，你的Java微服务需要通过这些组件来彼此通信。

可见，DevOps方面的复杂度被大大低估了。可以了解一下微服务测试类库，能在这方面对你有所帮助。

原文链接：

Java Microservices: A Practical Guide

创作场景

Java 微服务实用指南（一）