文章插图
如上面这个图 。
简单理解就是我只想做好中间方块内容，实现相关的功能和API接口的开发 。其它事情都不应该让开发人员操心 。
而其他事情就包括了这个组件本身的生命周期和运行时管理(容器云集成），东西流量管理（服务注册发现），南北流量管控（微服务或API网关），可观测性（状态管理，链路监控），服务治理（安全，限流熔断，日志审计）等 。
如果我是开发者我希望达到的一个目标就是方块外围的各种能力都不需要我在开发阶段去关心，都是应该在后续可以通过Sidecar边车代理的模式来灵活配置和实现 。
我开发一个微服务，重点是实现业务功能，并且写好我的对外接口函数 。
任何一个接口函数本身就应该具备多种接口协议的发布能力 。举例来说如果是内部的各个微服务组件之间的调用，应该自动化的发布为TCP+RPC调用模式以提升接口性能 。而对外发布才发布为Http Rest API接口以屏蔽防火墙影响等 。
而这些开发人员也不需要关心，也需要做到可以灵活配置 。
对于我开发自测通过的微服务，如果通过编译构建，打包，部署和最终交付到容器云平台，包括后续在容器云平台如何进行资源和状态的监控，组件资源的灵活动态调度，开发人员也不需要关心，微服务运行的全生命周期管理复杂性也不应该在开发态引入 。
只有这样开发人员真正的重心才能够放在业务功能开发，业务逻辑的实现上面，而不是去关注微服务技术平台 。
对于一个大企业也是同样的道理 。
大企业本身也应该是平台+应用的构建模式，可以有独立的技术架构和平台组来辅助微服务开发框架，技术平台，治理平台的建设 。而平台组提供给上层应用开发组的能力应该足够简单，不应该将微服务架构本身的一些复杂性引入到技术开发中 。
不是每个开发人员都需要去详细了解微服务架构，开发框架，各种微服务治理技术组件和底层实现方案，更多的开发人员应该是使用微服务开发框架，开发过程应该足够简单，真正将重心放在业务和功能实现上 。
这才是一个微服务架构设计的时候应该考虑的关键点 。
【微服务开发和治理-如何屏蔽软件架构的复杂性】
推荐阅读
- 前端开发网站推荐：作为前端开发，这27个网站可能会助你开发
- 2022 软件工程师状况报告：Go 最抢手｜开发者最“嫌弃”PHP、Swift
- 服务器安全加固_Linux配置账户锁定策略
- 这样加微信，通过率更高
- Nginx反向代理Grafana服务的配置步骤
- CentOS7下安装FTP服务
- APP开发用什么框架最好？这5大框架，开发者必备神器
- 乳房轻微疼痛怎么回事
- 无代码开发平台功能对比
- 微信图片过期怎么办？如何查看微信过期图片？3步即可