在介绍微服务之前先要说明一下说明是单体应用，这样就可以深入理解微服务的价值。
单体应用
对于Java而言一般单体应用使用MVC架构：（Spring + iBatis/Hibernate + Tomcat）
其优点是学习成本低，开发上手快，测试、部署、运维也比较方便，甚至一个人就可以完成一个网站的开发与部署。业务通常是通过部署一个WAR包到Tomcat中，然后启动Tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。
然而随着项目规模的不断扩大，一般会生产如下几个问题。
- 开发、测试、部署效率低下：当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次5分钟，等的花都谢了。
- 系统高可用性差 ：因为所有的功能开发最后都部署到同一个WAR包里，运行在同一个Tomcat进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个WAR包中部署的功能。比如某段代码不断在内存中创建大对象，并且没有回收，部署到线上运行一段时间后，就会造成JVM内存泄露，异常退出，那么部署在同一个JVM进程中的所有服务都不可用，后果十分严重。
- 团队协作开发成本高：开发、测试某一个需求时，当某一个功能有问题时，所有参与人员需要同时关注其中问题。
- 扩展性不够：无法满足高并发情况下的业务需求。
微服务
基于以上等问题的产生，微服务架构应运而生。
优点：
- 松藕合：在开发阶段或部署阶段都是独立的。
- 快速响应： 局部修改容易, 一个服务出现问题不会影响整个应用。
- 易于和第三方应用系统集成： 支持使用不同的语言开发, 允许你利用融合最新技术。
- 开发简单、开发效率提高：一个服务可能就是专一的只干一件事, 能够被小团队单独开发。
- 足够内聚，足够小，代码容易理解：团队能够更关注自己的工作成果, 聚焦指定的业务功能或业务需求。
当然微服务的缺点也很明显
缺点：
- 微服务架构带来过多的运维操作, 可能需要团队具备一定的 DevOps 技巧.
- 分布式系统可能复杂难以管理。因为分布部署跟踪问题难，当服务数量增加，管理复杂性增加。而且整个项目的功能是不变的，当拼图越碎，拼成拼图的困难度越大，所以复杂度肯定会增加很多。
- 通信问题：微服务之间的通信会影响效率，高效的通信是必不可少的。
- 系统问题：安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？
一个完整的微服务系统，它最少要包含以下功能：
日志和审计，主要是日志的汇总，分类和查询
监控和告警，主要是监控每个服务的状态，必要时产生告警
消息总线，轻量级的MQ或HTTP
注册发现
负载均衡
部署和升级
事件调度机制
以下功能不是最小集的一部分，但也应该在选择时进行考虑：
认证和鉴权
多语言支持, 是否支持多种编程语言
统一服务构建和打包
统一服务测试
统一配置文件管理
服务依赖关系管理
问题跟踪调试框架
灰度发布
蓝绿部署
资源管理，如：底层的容器, 虚拟机, 物理机和网络管理
微服务的实施是有一定的先决条件：
一。基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入较被动的局面。推荐采用CI/CI改进基础设施及运维的实践，通过自动化运维使得可以快速安全的响应和处理微服务对服务部署的要求，通过容器技术保证服务环境之间拥有更高的一致性。想要更好的实施微服务, 首先需要考虑构建团队DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源。
二。拆分出来的微服务最好不要涉及跨数据库表交互，比如用户用户跟订单，订单和商品等等这些数据之间都是有关联的，服务拆分之后会面临以下问题:1当需要读取关联数据时，如果采用表连接的方式查询数据会出现跨数据库查询的可能，2如果是通过RPC的方式多次调用(比如要查订单，就需要查询商品及订单详细信息)，也会出现多次调用导致的频繁多次的数据库连接，而如果使用缓存，也会面临数据库与缓存之间的数据同步问题，特别是数据库与缓存服务器都存在集群的情况下，会更难处理，这也是在做微服务之前必须要考虑的问题。
三。拆分微服务先要把业务梳理清楚。首先要做到心中有数，梳理清楚了那么业务的边界自然清晰了，自然而然对应拆分哪些服务也出来了，拆分的过程中一定是绞杀式的，新的需求自然放到拆分的微服务，老的逻辑按照优先级和重要程度一个点一个点的从单体迁移微服务，服务化上线之后，渐渐取代老的单体，等全部拆分完毕，线上稳定之后，自然就可以下掉老的单体应用。
总结来说，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率，并被各大互联网公司所普遍采用。
网友评论