应用?？榛低成杓圃虮苊馕⒎竦牟僮鞲丛有浴?/p>
已经有很多地方说过从单体应用迁移到微服务。除了动动嘴皮子外，好像也不需要花费很大的精力就能把单体应用拆分为微服务。但是这种方式真的对你的组织是最好的选择吗？当然也有很多缺点去维护一个混乱的单体应用。但是经常有个醒目选择被忽略：?？榛τ每?。这篇文章，我们将探讨这个并展示它与构建微服务的关系。
Microservices for modularity
“有了微服务我们的团队终于可以独立开发” 或者 “我们的单块太复杂了，都拖慢我们了”。这些说法仅仅是众多理由中的一点导致开发团队开始使用微服务。另一个原因是需要扩展性和弹性。似乎开发者们渴望一个?？榛姆绞浇邢低成杓坪涂?。模块化在软件开发里可以总结为三个原则：
- 强封装: 在组建里隐藏实现细节，降低不同部分的耦合性。团队可以独立工作来解耦部分系统。
- 好的接口定义: 可能隐藏不了所有的，所以组件之间好的定义和稳定的APIs 是必须的。一个组件可以被任何符合规范的接口替换。
- 显示依赖: 拥有一个?？榛低骋馕蹲磐耆煌淖榧餐ぷ鳌Ｗ詈糜幸桓龊玫姆绞矫枋鏊堑墓叵?。
微服务应该知道这些原则。一个微服务可以通过很多方式实现，只要为其他服务暴露了好的接口定义(经常是REST API)。它的实现细节在服务里面，并且可以改变不会影响到系统和协调。各个服务的依赖通常在开发期间不是显式的，可能会导致服务在运行期编排失败。我们可以说最后一个模块化原则可以使用在大多数微服务架构里。
所以，微服务遵循这些重要的?？榛颍嵊惺凳翟谠诘暮么Γ?/p>
- 团队可以独立工作和扩展。
- 微服务可以更下更专注，减少复杂性。
- 服务可以在内部里改变或者替换，不影响全局。
为什么不喜欢？好吧，只要你已经从单块应用(虽然有点臃肿)到微服务的分布式应用。就会带来超级操作复杂性。突然，你需要持续部署不同的服务(可能是容器化)。新的问题：服务发现，分布式日志，跟踪等等。现在可能就是分布式计算谬论。接口的版本和配置管理成为了主要关心的。这个列表还将会继续。
原来处理微服务连接有多复杂，组合各个微服务的业务逻辑就有多复杂。为了使用微服务，不能只是拆分单块应用。而在单体应用代码库里的“面条代码”是有问题的，在这些问题里改成微服务的网络连接更痛苦。
模块化选择
这是否就意味这我们要么使用混乱的单体应用，要么淹没在微服务的复杂性里了吗？?？榛梢酝ü渌侄问迪?。重要的是我们可以有效的在开发期间实现和定义边界。但是我们也可以通过创建好的结构的单体应用实现。当然，这意味着我们可以接受任何从编程语言里得到的帮助和开发组件定义?？榛颉?/p>
比如，在Java里，有很多?？榛低晨梢园镏峁够τ谩SGi是最著名的一个，但是随着Java 9的发布，原生?？橄低骋丫尤氲絁ava自己的平台里。?？榛衷谝丫怯镅院推教ǖ囊徊糠肿魑坏裙乖?。 Java?？榭梢栽谄渌？樯媳泶镆览?，发布类实现的强封装接口。甚至Java平台已经可以使用新的Java?？橄低衬？榛??？梢源?a target="_blank" rel="nofollow">Java 9 Modularity书里了解Java 9的?？榛?。
