你越不了解一个领域，微服务的界限划分就越难，出错的机率越大，成本越高~

大家好，欢迎来到程序视点！我是小二哥。今天我们从微服务的架构说起！

最后微服务架构图

微服务架构图谱，通过谷歌或Bing下，可以看到各种各样的架构图，源于业务和架构师自身的喜好或者粗细粒度。

就整体来说，每个架构图的基本组件和架构分层都差别不大，只是有的细一些，有的粗一下。比如有客户端层，容器层(K8S)，API Gateway，微服务集群层，EventBus层是必须要有的，至于服务监控和服务跟踪、服务治理本身就是一个完整的系统，粒度就没有细了。

基于以上这些概念，这里给大家分享一个架构图。这里省去服务监控跟踪和治理的部分，后续单独抽离出来分析。

这边的架构图谱更加贴近业务，粒度也更细。

以上架构图主要分4层，每个层次遵循架构分层的核心思想：关注点分离，职责各异，边界清晰。

第1层：客户端：理论上包含一切可以联网的设备，包括移动设备，Android、IoS、Pad、微信、微博、QQ、Web、各自浏览器、物联网设备等等……

第2层：API网关：包括服务注册，发现，认证授权，单点登录，熔断，限流……网关的知识点丰富，是微服务的核心之一。

第3层：微服务集群：包括各种具体的microservice，比如纵向划分的业务服务(用户服务，订单服务，……)，横向划分的基础或公共服务(元数据服务，公共服务……)

第4层：事件总线：Event Bus 目的是消息解耦，不要让服务之间直接的链接。不同与SOA的服务总线，事件总线相对比较轻量，经常基于消息队列引擎进行解耦，目的是为了让服务之间的关联弱化，不直接进行关联。很多时候用的是相对稳定、可靠、企业级的RabbitMQ。

微服务的架构其实不难，根据以上的架构，每种业务都可以进行套用，这里的难点在于服务的划分和粒度控制，另外如何管理膨胀的服务是一个麻烦事。

如何拆分微服务

如何正确拆分微服务呢？这里正确指的是合理，因为没有绝对的标准。按照前人的经验可以分为纵向和横向两种划分方法：

① 纵向拆分

是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务，比如上图中的订单服务，用户服务。另外粒度太小，服务聚合是一个坑，粒度太大，分和没分一个样。真的很需要经验！！！

② 横向拆分

是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。比如上图中的元数据服务和消息服务。

总结

借用《微服务设计》中的一句话：“你越不了解一个领域，为服务找到合适的界限上下文就越难……服务的界限划分错误，可能会导致不得不频繁地更改服务间的协作，而这种更改成本更高……”

软件行业从业者，尤其是那些已经不写代码的从业者，总会期望有银弹，但银弹终究是没有的：微服务依赖于“基础设施自动化”，微服务不是“银弹”。

最后

有关微服务的知识点非常的多。限于篇幅内容，今天先到这里。后续继续给大家分享更多的内容！