微服务
任何架构和开发方式都是基于需求演变而来的
单机架构
一台服务器或几台负载均衡的服务器运行一套代码实现所有功能叫单机架构
单体架构在业务逐渐负责用户量越来越多时候会遇到以下问题:
- 所有业务逻辑在一套代码实现导致功能耦合严重,难以维护
- 整体功能中的A模块出现Bug导致CPU/内存爆满或慢SQL会导致整个网站瘫痪
- 服务器和数据库扩容到会有一个极限,正常情况下最多到32核128G.并且业务低峰时不需要这么高的配置,降配和升配繁琐且会停服重启
服务划分
将功能基于 DDD 划分为不同的服务,例如一个完整的电商项目划分为
DDD 领域驱动设计思想是个很缥缈的概念,没有绝对的的标准.确保业务解耦即可.
- 账户服务
- 商品服务
- 订单服务
- 支付服务
- …
前期可以先按照功能划分,后续再细化.
分布式和集群
可以通过了解下分布式数据库,去了解什么是分布式
即使使用单机架构为了保证数据一致性也可以用分布式数据库.
集群通俗的说就是用很多台服务器干一件事
微服务尽量使用集群,将资源进行隔离
负载均衡
使用集群之后要讲用户的请求平均的分发到各个服务器.
可以使用 nginx 的负载均衡,或购买云服务的LB负载均衡服务
CDN也是一种负载均衡,因为几乎成为网站标配,这里就不再赘述了
负载均衡需要根据实际业务情况选择合适的负载均衡算法
数据隔离
不只是将代码进行服务划分,像数据库(mysql/redis/mongodb) 也应该进行划分.
- 账户服务使用数据库只能被账户服务访问
- 订单服务使用的数据库只能被订单访问
- 订单服务想要访问账户的数据,必须通过订单服务提供的rpc接口才能访问
这样做能类似避免单点大量慢SQL导致所有服务不可用的问题.
数据隔离后实现一些跨服务的业务逻辑时需要考虑分布式事务
数据水平扩展
服务器实现了集群,数据库也要实现集群和一些读写分离策略来避免单机数据库的性能瓶颈.
云服务提供了一些非常便捷的数据库中间件让开发人员更便捷的使用数据库