accountclassphp技巧_Java 微做事实用指南一

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

复制代码

@Controllerclass 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 文件就会变成一只巨大的、有千兆字节的代码怪物，每个人都不敢支配它。

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

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

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

全体提取过程本身会不会使你新的 RiskCheck 模块成为微做事呢，大家对微做事定义有着不同的阐明：

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

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

怎么做呢?

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

(http)/rest（同步通信）

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

如果你须要立即相应，可以利用 REST 通信，详细到我们的案例便是这样做的，由于在开户之前必须进行风险检讨：不做风险检讨，就不给开户。

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

通报（异步通信）

异步微做事通信常日通过 JMS 实现和 / 或 AMQP 等协议的通报来完成。
常日，是由于实际上如 email/smtp 驱动集成的数量是不可低估的。

有时，利用一个微做事并不须要得到立即相应，比如用户按下“立即购买”按钮并希望天生发票，则当然不必在用户购买这一要求 / 相应周期内完成。

在工具方面，可以看看哪些代理最适宜异步 Java 通报。

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

复制代码

@Controllerclass 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 银行运用这个庞然大物，并考试测验沿着领域边界拆分它，这不失落为一种明智之举。

现实：让别人来做

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

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

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

这些开拓职员现在要深入挖掘旧的遗留代码（它们没有清晰的数据库事务边界），并提取定义良好的微做事？可能是吧，但常日是真正的寻衅，是无法在白板或架构会议上办理的了的。

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

我一贯都说……如果你不能精确地构建大型独体运用，那么微做事也帮不了你。
Simon Brown

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

于是就产生了各种不同的方法，公司可以利用它们考试测验处理全新的 Java 微做事项目。

技能型微做事架构

对付开拓职员来说，立时就会想到这样一种方法，只管我们强烈建议不要利用它。
Hadi Hariri 在 IntelliJ 中提出了“提取微做事（Extract Microservice）”重构功能，这一点很是值得称道。

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

微做事之前

复制代码

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

利用了一个 substring 的 Java 微做事

复制代码

@Serviceclass 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 文件并做出处理（已做简化）：

现在，如果你考试测验利用微做事对这个事情流进行建模，至少会包括以上内容。

把稳：在本例中，微做事之间的通信与主题无关，但如果真要提一下的话，可以通过 RabbitMQ 之类的代理异步完成，由于年夜夫不需立即得到反馈。

同样的，从纸面上看，这彷佛看起来挺不错的，但我们立时会创造以下几个问题：

有趣的是，对付一些架构师来说，上面的图理解起来更大略，由于现在每个做事都有它确切的、定义良好的用场。
以前，它看起来像这个恐怖的大型独体运用：

虽然这些图画起来大略，但是你肯定须要办理些额外的运维寻衅。

你……

建议

除非：

否则：

不要这么做。

只管，没那么夸年夜。

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

因此，每当你开始一个新的、领域边界还非常模糊的 Java 微做事项目时，且领域边界仍旧非常模糊，请只管即便保持微做事的规模。
你总是能够在之后添加更多模块的。

确保在全体团队 / 公司 / 部门都拥有非常强大的 DevOps 技能，以支持你新的根本架构。

还有第三种，险些因此自由意志主义的方法来开拓微做事：让你的团队乃至个人有可能利用他们想用的任何措辞或微做事来实现用户故事（行业术语：多措辞编程）。

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

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

这意味着，该当有一套相对标准化的措辞、库和工具，这样即便你不在了，其他开拓职员将来也可以连续掩护 Haskell 微做事。

有趣的是，回溯历史可以创造，标准化走得太远了。
某些财富 500 强公司乃至不许可他们的开拓职员利用 Spring，由于它“不在公司的技能蓝图中”。

建议：

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

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

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

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

我们连续以上文的银行系统为例，我们现在有一个 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.jarubuntu@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.jarubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \...

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

对付 Java 微做事的支配，最无聊但又完美的答案是过去 20 年中管理员为公司支配 Java 做事器端程序的办法。
它包括：

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

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

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

如果你以前没有利用过它，那么可以先理解一下它对终极用户或开拓职员的意义所在：

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

但是，对付 PHP 或 Python 之类的措辞来说，情形就有点不同了，由于这些措辞的版本不相互兼容或其支配配置历来都比较繁芜。

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

以是，Docker 对付 Java 微做事，或者说 Java 运用程序的紧张好处在于：

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

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

假设你正在考试测验 Docker。
现在每次支配 Java 微做事时，你都要创建一个 Docker 镜像，它绑定了你的.jar 文件。
你有多少这样的 Java 微做事，你希望将这些做事支配到多少机器上：即集群。

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

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

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

那么，Java 微做事的支配过程现在看起来可能是这样的：

假设你办理了在生产环境中支配微做事的问题，但是在开拓过程中如何集成测试微做事呢？如何查看完全的事情流是否事情正常，而不仅仅是单一的局部呢？

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

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

可见，DevOps 方面的繁芜度被大大低估了。
可以理解一下微做事测试类库，能在这方面对你有所帮助。