微服务拆分原则
在微服务拆分中，核心需求在于拆开的微服务之间的联系越少越好，数据交互也是越少越好。因为微服务之间的数据一致性非常难处理，如果一致性方面的问题很少，整体做起来就比较简单了。
微服务架构选型
微服务架构的选型也是一个让人比较纠结的事。选择开源技术时，社区的活跃度是非常重要的参考。
第二个选型原则：一定要满足需求，这是要重点考虑的。
第三点原则是掌控能力，假设一个框架是用 C 语言写的，整个团队没有懂 C 语言的人，这样肯定不行。
因此，微服务架构选型需要考虑：社区活跃度、需求满足度、掌控能力这三方面。
微服务架构演进方式
再来说说微服务架构的演进。微服务是长出来的，而不是设计出来的。完全架空地去做一套新系统当然可以做好微服务架构，但很多时候我们没有这种条件，都是在一个已有的系统里去做。
因此，架构演进方式就是：有了新需求，做一个独立的微服务，慢慢做成服务化互相调用，然后把数据切分过来。
但数据切分也不是一次就做完了，而是数据先在存在于新老系统中，两边保持一致，逐渐再迁移至新系统。
最后的结果可能是老系统中还有残留，但是在它周边的很多新需求，全都是通过一个个独立微服务做出来的，这就是微服务长出来的方式。
在项目落地中，这种架构演进方式还是有很多风险的，也经常有客户采用完全中心开发的方式做微服务，比较简单纯粹，但需要多花很多成本。
微服务是需要大平台支撑的
微服务革新了软件的生产过程，包括开发、测试和部署各个阶段。但服务的切分并不是要遵守单一原则，因为未来的服务不可能完全垂直切分。
从另一个角度看，微服务的过程其实也是工业化的工程，每个微服务都是生产线上的一个零件，但要注意，零件的组装和拼接难度更大，所以在谈论微服务时一定要注意，它需要一个大平台支撑。
比如有自己的企业级 PaaS 整体解决方案，整个 PaaS 平台底层是容器平台，它是 PaaS 中的一个基础设施，再上一层有应用的开发管理，应用的部署上线，以及应用的运行管理和开发管理。
微服务的开发框架就跟开发管理相关。微服务咨询，这属于解决方案的一部分，包括了微服务拆分设计的咨询，以及微服务框架选型和微服务的开发指导，这两者属于开发过程管理。
对于微服务的发布上线和微服务运行的管理，还有服务治理，监控和服务治理是云平台管理的重要方面。微服务上线是容器平台的事情，微服务运行管理就涉及到服务治理。
除了上述四个方面之外，企业提升微服务落地的能力，最重要的是整个团队要达成共识。现在开发团队经常会听到两种声音，一是希望借助新技术，发展新东西，二是希望按部就班，不做改变。前者和微服务是比较匹配的，后者对微服务是一种阻力。
所以首先需要团队达成共识，如果第一个微服务试点项目失败，可能之后很长一段时间内都没有机会落地微服务了。其次，团队要做好心理准备与知识储备，因为微服务对开发、测试人员都带来了挑战，如果没有准备好，可能就需要花更多时间。
总之，微服务之路的想法是好的，但是在追赶微服务浪潮之前，企业和团队应该负责任地考虑，做好权衡取舍，切忌盲目跟风。
微服务架构首先要关注的不是概念与技术框架，而是服务的边界、职责划分，划分错误就会陷入大量服务间的相互调用和分布式事务中，这种微服务实践带来的不是便利而是麻烦。本文地址：https://blog.csdn.net/peter7_zhang/article/details/107373880
如对本文有疑问， 点击进行留言回复！！
step2：使用LitePal操作数据库，基于AndroidStudio。练习
shell练习：使用脚本同步系统时间 + hello world
荐 Kubernetes+docker 浅述-针对云平台测试
项目繁多的情况下，如何通过组织机构的调整管理好重点战略项目？
我要评论
网友评论