微服务在互联网公司演进过程

原文链接： http://mp.weixin.qq.com/s/KKL9aYOkkwHG358eexuC0A#rd

一.微服务由来

微服务不是被发明出来的，而是从现实世界中总结出来的一种趋势或模式。

多端技术促使了服务架构升级为微服务架构，而互联网加速了微服务架构演进。

微服务架构更关注广度(大方向)并兼顾重要细节，满足现有需求同时能应对将来的变化。

二.微服务的发展

2.1、面向服务架构SOA与微服务的关系是什么？

SOA在发展过程中，由于厂商添加了太多元素(很多是出于销售原因)，把面向服务的架构SOA搞的声名狼藉，同时SOA本身模式上也存在一些问题。微服务社区的很多技术人员都具有大型机构整合服务经验，他们深知仅仅SOA已经不能完全涵盖服务经验，再加上互联网的发展，让这些整合服务经验传递出来，于是微服务倡导者拒绝继续使用SOA标签。但还是有不少人认为微服务是从SOA中发展而来的，或许面向服务是对的。

2.2、微服务架构是否需要不断演进？

设计合理的服务是要对系统有足够的认识,从模块到服务边界以及暴露的内容都需要很高的认知，并且还需要很多设计理论支撑。微服务架构提倡持续改变和演进系统，变化无法避免，拥抱变化才是王道。

-工具支持

-制定原则

-实践

三.微服务模式

3.1、微服务架构的主要好处有哪些？

技术异构性

弹性

扩展

简化部署

与组织结构相匹配

可组合性

对可替代性的优化

3.2、微服务怎么衡量好坏？

（1）、松耦合。 修改一个服务不需要修改另一个服务，最小知识原则，基于接口设计，API技术无关性。

（2）、高内聚。把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离

开来。

3.3、微服务粒度如何衡量？

不能以代码行多少来衡量服务粒度。比如像Kotlin语言能使用很少的代码完成其他语言相同的功能，还比如一个服务的代码可能有多个依赖项，而每个依赖项又会有很多代码,再比如有的领域对象本身很复杂，服务的本质不应该在过渡强调服务的大小服务粒度与团队结构相匹配，如果代码库过大，一个团队无法正常维护，即可仅一步查分。

3.4、服务与应用的关系？

服务和应用可以一对一，也可以一组服务集一个应用，服务集通常是一个独

立的业务模块。但如何选择要看团队组织，只要与团队能力匹配即可。

3.5、微服务如何建模

建模是一种能力，是需要有专业知识加业务理解。参考《微服务设计》、《领域驱动设计》等书

四.微服务架构在五阿哥的演进

4.1、工具化-架构/运维/开发

完善服务治理

依赖关系管理

接口设计平台

服务编排

更完善的监控

安全控制

4.2、制定微服务原则-架构

让目标和大方向一致，比如：一致的接口和数据流

4.3、实践，更细粒度的约束-开发

关注服务边界和边界内的事情，把服务做到合适。实践出细粒度规则，做好服务的粒度及服务暴露的粒度需要比较高设计能力。

文藏来源：五阿哥技术部架构师：菏泽