微服务架构实践
文章目录
微服务架构就是把大的复杂系统拆分为若干个小的独立的服务， 每个服务运行在自己的进程中，并采用轻量级的机制进行通信（一般是 HTTP 资源 API），通过全自动部署工具来实现独立部署。这些服务都是围绕业务能力来构建，可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。
微服务优势
- 拆分，大拆小，复杂简化（包括团队拆分、业务拆分、系统拆分）
- 并行开发，一个微服务只需要关注特定业务，不同团队、不同代码库，互不影响
- 技术栈不受限制，微服务之间采用标准Restful接口规范，跨语言，跨系统整合更简单
- 最小化升级迭代，一个微服务的升级不影响整个对外服务
- 灵活扩容，针对系统具体业务瓶颈，只需要扩容个别微服务，动态调整每个微服务的负载能力，最大化利用硬件性能
微服务挑战
- 开发成本，微服务开发需要开发人员考虑集群部署、分布式事务、接口幂等、版本控制等，当涉及多微服务联调时，需要启动多个微服务，对开发机器内存也有一定要求
- 维护成本，因微服务调用关系复杂，增加了联调测试、问题定位的难度
- 分布式事务目前还要自己实现微服务级别回滚
- 运维成本，为了发挥微服务的优势，微服务建议集群部署，对服务器的要求较高
Spring Cloud
目前主流的微服务框架有Dubbo和Srping Cloud，Dubbo 主要只是为了解决服务通信、服务注册等问题，而 Spring Cloud 却是提供微服务架构的完整的解决方案。从知名度、社区活跃度、架构完整度、异构系统整合能力，Spring Cloud都远优于Dubbo，Spring Cloud目前已经成为微服务架构的标准框架。
Spring Cloud的基础组件如下：
- 注册中心：主要负责微服务应用的注册、发现和路由
- 配置中心：主要负责微服务配置的统一管理
- 服务网关：主要负责微服务对外统一网关
- 消息队列：主要是微服务之间的异步消息
- 批处理组件：微服务的定时任务管理及调度
- 日志分析：微服务日志查看、归总、追踪
实践建议
- 根据场景谨慎选择是否使用微服务，微服务不是万能的也不是所有场景都适用的，切记不要为了微服务而上微服务。
- 使用Spring Boot可以轻松地创建独立的、生产级的、基于 Spring 且能直接运行的服务或应用程序，使用Spring Cloud可以将一系列基于Spring Boot的服务或应用协调起来，构建成一个分布式集群系统。
- 无论是单体应用还是微服务应用，采用Spring技术栈，可以享受世界最活跃开源社区的支持，也可以享受国内的基数最大的java人才红利。
- Spring Cloud定位于为开发者提供一套开箱即用的微服务组件和可扩展的组件标准，有着丰富的可替换的第三方组件。
- 插件式改造
目前Spring Cloud还在高速迭代中，为了能快速跟上新版本，不建议对内核做深度定制，好在spring的扩展性都非常好，总有一种方法让你以插件式方案来完成自己业务特性定制。 - 自动化DevOps
微服务架构是人肉测试和运维的噩梦，如果不能同步推进自动化DevOps，请不要尝试。 - AKF拆分原则 参考《The Art of Scalability》，应用扩展的三个维度
- X轴: 水平复制。集群负载均衡的模式。
- Z轴：数据分区。水平复制撑不住了，就可以将数据进行分区，多建几个集群。
- Y轴：业务拆分。微服务的拆分模式。