目录
背景
项目中有幸接手了一个“微服务”架构的项目，然后从开始的各种不方便，上手慢，到中期的硬着头皮上，吃得苦，霸得蛮；再到最后的励精图治，舒经活络。我对于“微服务”架构也有了一个不深不浅的体会和认识。所以借github这块宝地也说说自己的一些事后感想。
概念
微服务是一种功能应用的架构和组织方法，其中功能应用由通过明确定义的 API 进行通信的小型独立服务组成。这些服务可能由各个团队独立负责。
特点
- 自主性
可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。 - 专用性
每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。
架构
微服务典型架构
微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
结语
微服务整体实践下来，是个有想法的设计架构，但绝不应该作为一个噱头去使用，要知道没有最好的框架，只有最合适的。它的使用应该是使其项目不受限于某种开发语言，某个开发团队，某个功能点。而是应该让其充分“解耦”，但这其中一定需要规律的去组织，去约束，因为只有做到“约法三章”，才不至于因为使用微服务架构开发导致整个项目的内部实现看来“随心所欲”，要知道，如果真的不加约束和管理，那么对于项目后期的维护和扩展来说将会是相当可怕的。希望大家客观看待微服务，理性且慎重的组织项目的整体规划。
0 条评论