踩坑实践：如何消除微服务架构中的系统耦合

　　58 速运的微服务实践

　　我们通过实践形成了一套技术体系，从而更快、更好地支持了自己的微服务架构：

　　统一的服务框架

　　我的建议是：要在一开始就定下整体统一的基础体系，通过统一语言、统一框架，来减少重复开发。

　　例如 58 同城很早就统一了自研的框架，尽管初期并不太好用，但是随着时间的推移，它被慢慢地改善且好用起来。

　　统一数据访问层

　　如果有的团队用 JDBC，有的用 DAO，这样重复的成本会很高，因此一定要事先达成共识。

　　配置中心

　　早期各个 user-service 的 IP 地址都被写在配置文件里，那么一旦服务需要扩容出一个节点，就需要找到所有调用它的上游调用方，告知 IP 地址的变更，调用方再各自经历复杂的修改，并配以必要的重启。

　　而如果我们使用的是配置中心的话，则可以通过简单配置，以平台发通知的方式，告知 IP 的变更，进而所有调用方的流量都会被迁移到新的节点之上。

　　服务治理

　　包括：服务发现与限流等一系列的问题。例如：某个上游的调用方写了一个带有 Bug 的死循环，导致将下游所有的调用次数都占满了。

　　那么我们可以运用服务质量的治理，根据调用方的峰值来进行配额和限流。

　　如此，就算出现了死循环，它只会把自己的配额用光，而不影响到其他的业务线。

　　可见服务质量的管理对于服务本身的快速扩/缩容，以及遇到问题时的降级，都是非常有用的。

　　统一监控

　　为了实现统一的服务框架和数据访问层，我们可以在框架层的请求出入口、在 DAO 的层面上、访问数据库的前/后、访问缓存、以及访问 Redis 的 MemoryCacheClient 时简单包装一层。

　　从而 hook 这些节点，快速地监控到所有的接口、数据库的访问、缓存访问的时间。可见在框架层面上，所有的接口都能够被统一监控到。

　　统一调用链分析

　　由于微服务化之后，层次关系变得复杂，因此我们需要具有一个调用关系的视图。

　　如果出现某个请求的超时，我们就能迅速定位到是网络、是数据库、还是节点的问题。

　　自动化运维平台

　　通过调节服务的上限与扩容等操作，让服务化给技术体系带来更大的便利。

　　总结

　　微服务解决了：代码拷贝的耦合，底层复杂性扩散的耦合，SQL 质量不可控，以及 DB 实例无法扩容的耦合问题。

　　同时，微服务带来的问题有：系统复杂性的上升，层次间依赖关系变得复杂，运维、部署更麻烦，监控变得更复杂，定位问题也更麻烦等。

　　因此服务化并不是简单引入一个RPC框架，而是需要一系列的技术体系来做支撑。

　　我们需要通过建立该技术体系，以解决如下可能面对的问题：

　　统一服务框架和数据访问层(包括：数据库的统一访问、缓存、Redis 的 MemoryCache 等)

　　配置中心和服务治理

　　统一的监控

　　调用链

　　自动化运维平台

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!