本站整理下载：

 

相关截图：

 

主要内容：

在正式讨论微服务架构前，有必要用简短的篇幅，讨论下微服务以及这种架构风格的优点和缺点。 在微服务出现之前，我们的架构多数是单体应用架构。会有一个或者少数几个”巨无霸“进程，里面可能 包含了”用户管理“、”订单管理“、”支付确认“、”物流“等等各种复杂的业务逻辑和功能。这种传统的 单块应用架构风格是很直观、自然的，然而在现代软件开发领域，特别是互联网开发领域中，单块架构 遇到了一些问题。 单块架构的缺点 耦合严重：单块服务内的各个逻辑之间，往往缺乏清晰的边界。导致内部耦合严重，正所谓“牵一 发而动全身”。 维护困难：单快服务包含了过多的业务，代码量严重膨胀。开发人员难免”失焦“，不知道如何下 手。团队协作困难：如果多人同时开发同一个单块应用，势必导致代码冲突成为常态，团队协作成本 急剧上升。 测试困难：单块服务是作为一个整体进行开发、上线的。尽管你只对Ａ功能进行了修改，但难免 会影响Ｂ功能。随着单块应用的愈发膨胀，测试工作量会提升数倍。 上述单块应用的缺点，在传统软件开发中，尚可通过“小心规划”、“人海战术”等方法解决。但到了互联 网时代，就很难实现了。为什么这么讲呢？互联网软件开发，讲究的是“快糙猛”，对迭代速度的要求非 常高。对于成熟的互联网企业，一个项目在一天内上线好几次，都是稀松平常的事情。试想一下我们的 单块“巨无霸”服务，稍微改动一点，就要经过复杂的代码评审、测试验证，如何才能跟上快节奏的迭代 和上线呢？ 尽管微服务不是银弹，但微服务的出现，确实从一定程度上改善了这种情况。微服务是⼀种架构⻛格， 将单块应⽤划分成⼀组⼩的服务，服务之间相互协作，以组合的形式，实现复杂的业务功能。 微服务架构的优点 低耦合：在单块服务中，不同业务的逻辑耦合在一起。做微服务拆分后，微服务内只包含有限的 业务逻辑，耦合也随之大大降低。 易维护：微服务内部只包含单一业务逻辑，功能更为集中，更容易开发人员聚焦问题和修改。 适合团队协作：拆分为微服务后，每个服务中涉及的代码和功能更少，可以将不同微服务划分给 不同团队甚至个人负责。各司其职后，有效降低了开发和代码冲突，使得其适合团队协作。 测试成本低：在单块服务中，哪怕只改动了一点点代码，也需要对整个巨无霸服务进行测试。微 服务拆分后，功能的修改，只需要涉及改动的个别微服务进行测试，有效降低了测试工作量。 易横向拓展：在单块服务时代，巨无霸服务已经占用了大量资源，机器的配置已经很高，若要再 单独部署一个结点做负载均衡，成本会非常很高，所以多数情况下，都是通过纵向拓展的方式提 升系统性能（如加内存，换个更好的cpu）。采用微服务拆分后，各个微服务占用的资源更少，