微服务的概念与早期IBM的SOA的概念（08～10年做项目基于上都是套用SOA），有着异曲同工之处，都是基于模块化的思路来实现高内聚低藕合的系统设计理念，只是它们的实现方式不同而已，比如基于EJB(RMI)来实现SOA，基于Spring-cloud/dubbo(Http/RPC)来实现微服务。微服务的概念从提出的那一刻起，已经在技术圈火暴到现在，算是比较成熟的系统设计与开发理论。微服务简单点说就是通过开发一组小型的服务（模块）来构造一个独立的应用系统，每个小型的服务都运行在自己的进程中，通过特定协议的API来相互通信，达到模块化应用系统的目的。从微服务的概念，可以看到有如下的优点：
1、 模块化开发与维护
业务拆分成不同的小型服务，每个小型服务只专注特定的业务（比如商品可为一个小型服务）领域，实现业务功能的高度集中，降低传统业务堆积在一起，难以维护的程序，方便对业务的理解、运维、调度，提升服务的可维护性。（前提是业务和技术要有高度，能很好地划分业务领域与边界，不然会越做越乱）
2、 故障隔离
某个小型服务宕机，不会影响到其他服务继续使用，避免了单体应用宕机后，系统不能使用的情况。（前提是要做好服务与服务之间的融断机制，如果没有处理好融断机制，一样可能引起整个系统的雪崩）
3、快速响应局部需求/修复的上线
基于小型服务的特点，对于线上的问题，或者特定业务领域的需求的开发，可以做到快速的开发与上线，而不会影响到其他小型服务的继续使用，有别于传统的单体服务，需要整个系统重测及停机上线。（前提是需求不会涉及到整体的功能）
4、技术栈不受限制
微服务都会有服务发现与注册中心，来负责调试不同的小型服务，只要小型服务的数据通讯协义是共同，可以采用不同的技术栈来进行开发，如java、.net等，也可以采用不同的数据，如mysql 、oracle、SQL Server等。（前提是要有统一架构标准）
基于微服务的优点，在公司的很多项目中，就在计划及实施微服务，解决单体项目在业务不断扩展，功能不断堆积后的开发，上线及运维的困难，通过不断的研究与测试，开始从与业务无关性的基础服务迁移到微服务体系中，通过一年左右的时间，实现了Java体系的都所系统微服务化，从效果上，确实验证了微服务的优点，服务化后各小型服务专职特定的业务，降低互相依赖的关联，开发人员专注度更高，在当时确实提升了系统运行的稳定性，虽然在过程中不知踩过多坑。
但随着业务的发展及功能的越来越多，小型服务越来越多，微服务的优点是需要付出代价的，它的基础是要有一定的团队规模（与服务数量有关）、运维人员、产品与技术相结合的高度才能保证良好的运作，适用于成熟的系统平台，不适用于项目初期的快速迭代升级。总结来说，有以下的问题：
1、降低开发效率，可能增加开会周期
拆成多个小型服务后，可能一个需求的开发，会涉及到多个服务的同时开发，这个在当初的商城开发中经常遇到，尽管当初的开发人员还是比较多，但效率还是低下，微服务是告别直接查询数据库，采用标准协议来通讯（API接口），也就是接口对接，需要多方人员进行沟通确认（沟通成本），结果核对（对接成本），可能还会一份数据存在多个数据库中，通过接口同步来同步去。这个就好比去市场买菜，如果一个去，直接按清单买就完，如果分派多个人去，要先跟每个说买什么买多少，买回来后又要核对一遍。
2、产品与技术的高度
如果产品经理与技术架构不能很好的配合，思路碰不到一起去，那是没办法实施微服务的，最终就是边界不清，没办法将要开发的功能落实到各个小型服务中，反而会确觉这个不适用，那个不适用，不如重新开发一个。到最后会发现，各个服务之间调用比蜘蛛网还要复杂，可能会导致需求都改不动代码，还不不拆时好处理，变得难维护。
3、数据不一致问题（业务数据算多算少的问题）
相当大家都有这样的经历，在传话的过程中，信息会变多或变少，从上往下，如果不记录，路径越长，信息会越来越不准确。实现微服务也有这样的风险，服务拆得越多，调用的路径越长，数据的不一致性会越来明显。但在单体项目中，这种情况会很少，它可以通过事务来统一处理，微服务难通过事务来保证，它的服务调用都是异构环境，一般只能采用数据最终一致性的策略来保证，但这个过程需要架构及开发人员有高水平，不然就会导致业务数据重复，或者丢失，严重的会造成公司的损失（比如处理钱相关的程序）。
4、沟通与人员成本
拆成小型服务后，需要有匹配的开发人员，也有对应的运维人员，服务拆得越多，需要更多的服务器资源来运行；相对于单体项目，人员的成本会高很多。
5、维护成本加大
服务拆分得越多，维护的成本就越大，需要增加对各种服务的监控、事件的预警；升级改造也会增加工作量（涉及大量服务更新时）。
6、问题排查困难
在传统项目中，可能找问题只需要在一个日志文件中就可以查找，但如果拆成微服务后，用户的一次操作，日志可能会分布在多种服务的多个文件中，在系统出问题时，排查起来的复杂度变高，时长会变长，在评估问题时，需要找到每次服务调的输入输出，不然难分析问题。（但这个不是不能解决，可以部署链路日志收集程序来采集所以的日志，汇总起来供查询）。
7、硬件成本增加
拆成多个小型服务后，需要更多的服务器资源来支撑其运行，如果资源不足，是无法运行的，每个小型服务的运行，是要有一定的资源基础，还有运行产生的日志会占用资源。
这里没有说单体项目有多好，微服务有那些不好，是没有确定的说法，它的存在自有它适用的场景。一般在业务探索的阶段，以快速响应市场需求的变化，是不建议采用微服务，除非团队成员够支撑，不然开发效率反而会降低。试想想，在项目的试错阶段，就去搭建一个大型公司的微服务架构，可能是浪费资源，而且也不能及时显应变化，需要大量的团队成员来维护，不然效率会很低下。如果平台成熟定向，是可以按微服务的方式来运作，按不同的平台功能分支进行扩展，降低具体某个项目的复杂度、维护量，形成多个小型服务，但也必须在产品与架构达成一致的前提下进行。
架构的选择，是平台/系统在发展不同阶段的选择，不能为了架构而架构，过早的去优化架构，在后面都会形成技术的债，可能会让进度陷入困境，但做平台/系统开发，也不能放弃对先进技术的研究与实践，这也就是我说的“不要迷信微服务，但也不要放弃对微服务，中台的迷恋与追逐”。
