微服务之--------如何实施微服务?

如何实施微服务?

这是在准备采用微服务之前需要考虑的问题,如果你也有和我一样的需求(不熟悉微服务或者使用微服务之前考虑事宜),可以参考一下这篇文章.

此文章内容非出自本人,而是出自翟永超的<<SpringCloud微服务实战>>(有兴趣的朋友可以留言或者去搜索,网上挺多资源的),都是本人的总结以及一些理解,或许会有异议,但是源头都是来自书中,对于初期或者在玩微服务的朋友来说,这本书绝对是本好书........

本人不生产,只是搬运工...

什么是微服务?这里不做解析,有什么问题可以留言.

一.缺点

　　1.运维新挑战:

　　　　因为微服务都是独立运行的,有些甚至是运行在不同的平台,并且业务发展快速,服务成倍增加,要让这些服务有条不紊的组织,编排起来不是一件容易的事情,需要运维人员有更多的新技能来应对这些事情.

　　2.接口一致性:

　　　　虽然我们将服务都拆分成了无数个独立的接口,但是业务上的依赖依然存在,所以在两个服务修改起来需要双方的互相协调,需要更加完善的接口和版本管理,或是严格遵循开闭原则.

　　3.分布式的复杂性:

　　　　由于拆分之后的服务存在于各个独立的进程中,他们之间的协作是靠通信进行的,所以分布式环境的问题是系统设计的一个大问题,比如网络延迟,分布式事务,异步消息等都将是一个极大的挑战.

二,特征

　　1.组件化

　　　　每一个服务都已经拆分,都是独立开发,独立部署,互相不会影响.摆脱传统修改其中一个接口需要整体部署.

　　2.按照业务组织团队

　　　　　单体应用中,如果需要在页面添加一个字段,那么修改的部门有DBA,运维,后端,前段,设计师等,虽然修改的都是极小的内容,但是内耗(部门协调以及耗时)却是非常大的.所以建议按照业务组织团队,

　　　　提升开发效率以及更好的把控团队.

　　3.做产品的态度

　　　　这个就见仁见智了,因为有很多时候业务中发生的特殊或者异常问题,项目经理或者产品经理都并不知晓,但是程序员却很容易就发现的需求,需要他们提出来一起去完善项目.

　　　　对程序员的有一定的要求,要求每一个程序员都要有做产品的态度,而不是为了交付或者完成开发的态度.

　　4.智能端点和哑管道

　　　　这个其实我不是非常理解,原文如下:

　　　　

　　　　5.去中心化处理

　　　　　　简单的来说,各个服务之间需要轻量级的契约定义接口,可以根据各个服务的业务特点采用更加好的技术去服务,如日志方面的可以用MongoDB,用户信息却用Redis等等...

　　　　6.去中心化处理数据

　　　　　　我们都希望将各个服务都有自己的数据库,让数据更加细致化,但是这样就会带来一个问题.数据一致性,所以更加强调服务之间"无事务"调用,而对于一致性,则只要求最终一致即可,如发生错,需要

　　　　　通过补偿机制去处理,使得错误数据最终到到达一致.

　　　　7.基础设施自动化

　　　　　　由于拆分的原因,在业务疯狂发展的现在,服务基本成倍的增加,对于运维来说,这将是一个噩梦,所以我们需要自动化测试以及自动化部署.

　　　　8.容错设计

　　　　　　在微服务中,为了避免故障蔓延,我们需要一套较为完善的日志监控组件,每一个服务中我们都需要实时的关键数据,如网络延迟,吞吐量,断路器状态,服务状态等等.才能快速的检测出问题.

　　　　9.演进式设计

　　　　　　这个的话比较见仁见智,我直接上原文吧,原文:

原创文章,转载需注明出处,谢谢.