微服务架构实践问题及建议

微服务概念提出者ThoughtWorks首席科学家MartinFowler 在Monolith First中写道：

i. Almost all the successful microservicestories have started with a monolith that got too big and was broken up

ii.Almost all the cases where I've heard ofa system that was built as a microservice system from scratch, it has ended upin serious trouble.

所有的成功的微服务的故事都是以单体应用太大开始的，逐步的拆分。我听到的所有的一个从无到有被创建为微服务的系统，他们都以遇到很大麻烦而告终。

采用微服务会带来很多问题：

依赖关系。原来一个应用可能会被拆分成几个或者几十个应用，服务数量爆炸式增长，导致依赖关系复杂，除非有一套非常好的服务注册发现机制，漂亮的依赖关系统计图，否则在服务数量超过100的时候，无论哪个架构师都搞不明白他们之间到底是什么关系。同时对开发人员遵守标准、规范的要求也空前提升。

性能。原本进程内的调用关系变成了网络调用，一次rpc变成了几次或者几十次rpc，同等条件下性能损失严重。（如果采用http+json，比netty+kryo、protobuf、thrift又会下降几乎一半性能，包括响应时间和吞吐量）

一致性。原本本地事务有可能变成了分布式事务，这个非常考验服务切分的规则，考验架构师对业务的理解程度。就算采用最终一致性，也要在各个服务中做好容错机制，假设调用失败如何处理，如果重试，重试几次失败怎么办？调用成功，返回ack失败时，怎么保证生产者的幂等性。

复杂度。服务数量多，依赖关系多，给开发、测试都带来了更大的挑战。架构师也需要定义一些规则，服务分层。例如服务分为原子服务、组合服务、流程服务，下层是不能调用上层的，如果允许调用，会导致循环依赖的问题。同一份数据可能上上下下调用了好多次。有可能只需要调用一次原子服务，因为上层的混乱，下来可能变成了几次。

要做好微服务，先要解决的是相关的框架、中间件、组件、通用服务。在这些都准备好的了情况下，业务开发人员根本不需要关心太多。举几个例子，

要解决依赖关系问题，就要有一个服务发现注册中心。

要解决性能问题，读的问题可以通过缓存来补偿。可以采用并行、异步、非阻塞等方式补偿性能，当然这些都可以封装到通用的rpc框架里面。

要解决一致性问题，就要有一个通用的事务处理平台。如果采用最终一致性，就把重试策略封装到框架。

要解决复杂度问题，就要定义一系列标准、规范，通过工具来检测问题。建立一整套devops平台，自动化测试平台。通过调用链分析，迅速定位问题。

总结：做微服务之前，需要审视一下，目前的业务场景、技术实力，是不是需要把应用拆分到“微”的粒度。优雅的架构总是和实用的架构有距离的。在没有足够的能力之前，应该尽量选择更实用的架构。如果你的体量还不大，首先应该解决的是搭建好一套绝对稳定的平台化服务，待体量逐渐长大，再去根据实际需要进行不断发分裂。团队也随之变化。如果体量足够大，饱受单体应用之苦，也应该先建设平台化服务，建设好之后，先按照大的粒度进行拆分，逐步“微”化。

微服务之所以被炒的如此之热，主要是因为容器的出现，PaaS服务提供商，不断的鼓吹微服务带来的好处，以此来吸引众多中小开发者使用其服务。

摘自：微服务年度总结，看完这个你应该知道如何回答别人的问题了。

微服务实战中的那些“坑” 从别人失败经历中吸取经验教训，在实践微服务时还要注意：

1、开发人员间达成共识，尤其是要说服哪些对微服务有抵触情绪的开发者很困难，在加强宣贯的同时为大家准备必要基础的培训、采用微服务的好处和必要性，进而让大家达成共识很重要。

2、做好服务功能定义、粒度划分，规范接口API文档、通信协议，对架构师设计能力要求高。

3、做好项目管理，更重视运营，自动化部署运维