标签：自动化运维 调度系统 修改 实践 独立 升级 elastics 直接 性能
微服务这几年很火，但真正实践了微服务，理解微服务的本质却很少。大家都在讨论一个看上去很美的微服务，但是实现起来，却毫无章法，该入的坑一个不少。那么到底什么是微服务呢？其实就是之前SOA服务化的延伸，在实现层面更加轻量。如果非要给个定义：
微服务就是一些协同工作的小而自治的服务
这么简短的一句话，实际上隐藏的很多点。简单说来：
小。就是专注做好一件事。记得刚开始流行的时候，甚至有的团队讲自己的微服务，只有一个接口。
自治。独立的实体，可以独立提供接口、独立部署、独立进行修改升级，总之就是独立。
协同。微服务会比较多，如何协作，统一管理？
什么是服务，大家要提问么？这个自己理解吧~。其实上面的两点，展开有很多的问题，第一个微服务到底多“微”，难道真的是一个接口么？这有一个权衡的问题，所以，微服务设计的本质就是：
如何寻找平衡
其实做过架构的同学，都知道，架构的精髓也在这里，乐趣也在这里。平衡做好了，怡然自得。
还有，上面也讲过微服务变小之后，相应的服务的数量就增加了。这么多服务给运维的工作带来了巨大的挑战，所以是一个很大的难点。没有成熟的自动化运维、监控的体系，还是不要玩微服务了，不然到时候手忙脚乱上线就要延期了。有同学会讲docker，确实如此，不过docker集群的成熟度，也是近一年才刚刚起来，很多团队我想应该还玩不溜的。
简单介绍下我们的技术栈，想要交流的同学可以后台留言。
微服务框架：GRPC
服务注册发现：自研动态DNS
分布式追踪系统：zipkin
自动化部署，资源管理调度系统：基于mesos+docker自研
错误报告聚合：sentry
自研API Gateway
这篇文章的题目是业务系统如何微服务化，上面讲了好多不着边的，大概当做背景的介绍吧。自动化的运维很难，但实际上更难的是微服务如何划分，划分的度如何把握。大家都知道，业务系统的逻辑非常复杂，模块之间的交互也是非常多的。所以做成一个单体的应用似乎更方便，所以大家应该有这样的经历：“直接join，多方便呢？”确实很方便，但是后期的扩展呢？性能的考虑呢？我们在实践的过程当中，经历了很多服务的拆分、合并、又拆分的过程。对于关系繁杂的微服务如何为服务化，有一些经验和大家分享交流，其中最重要的一条：
控制好服务的粒度，做好聚合
微服务架构演化中，渐渐会出现明显的分层。底层的服务，粒度小，真正意义上的微服务，提供单一功能。上层的服务，根据业务的需求进行聚合、过滤等功能实现，其中Gateway的重要职能之一，就是这个。所以想RabbitMQ、Elasticsearch等基础服务，在拆分聚合的过程中扮演着重要的角色。Gateway也有一些开源的实现，比如Kong，成熟度也算比较高，但针对实际的场景，无法很好的满足。这也是我们选择Gateway自研的主要原因。在实际的过程中，Gateway也不会只有一个而是多个。像我们根据产品分了不同的Gateway，不同的App，不同的Web产品，都是不同的Gateway，做不同的聚合，有共用的聚合，可以拉一个聚合层。这样做到很好的自治，各个应用之间影响尽可能的降低。
那么最底层的服务、自小粒度的服务该如何定义呢？有较多业务经验的同学，很快就会有答案，其实就是数据的模型。我们开发业务系统，重中之重的就是数据模型的定义，模型定义得好、清晰，基本上编码开发就会很顺畅。所以领域建模很关键，根据业务职能划分清晰领域模型的边界，就等同于明确了微服务的边界。然后，将关系交给聚合层。整个微服务的架构，已经开始良好的运行。
标签：自动化运维 调度系统 修改 实践 独立 升级 elastics 直接 性能
原文地址：https://www.cnblogs.com/dadadechengzi/p/8810208.html
