微服务之高效代码架构

高效的代码架构

        微服务作为为了解决复杂的业务架构而产生的技术解决方案，从理论上就为业务项目的快速迭代提供了可能。不过虽然从业务开发上降低了业务之间的耦合，可以通过投入各专业人员，提高协同效率，来提供开发效率，但是影响开发效率的还有个更重要的，就是代码的结构，专业话语就是代码架构，好的代码架构可以提升人效，微服务架构可以提升团队效率。

        那么什么样的代码架构是可以算高效的，我个人认为有以下几点：

1. 业务功能有分层，代码业务逻辑层次分明清晰，
2. 编码要基于现实逻辑，业务迭代的逻辑跟代码结构和层次逻辑保持一致
3. 变化的角度看待需求，能适应用户需求的变化的

完成构建高效代码架构

接口规划

        每一个服务都是处理一个业务领域关系的，而这个领域所提供的能力，解决什么样的问题对外部来说都是通过接口来实现的。那么接口的迭代规则是什么样子的，包括版本号更新，核心能力提供都是需要提前制定好的。

•  提供关键核心能力的接口的原则是要保证尽量时不要变化的
• 有些需要关键的能力需要升级的是采取兼容模式，还是升级版本
• 版本号更新的规则是采用什么来决定，对应版本有不同的业务规范，不同业务流程等

上下文规划

        任何一个服务代码，所处理的业务领域内的逻辑，都需要有上下文来进行业务关联逻辑处理的。上下文就是承上启下的功能，知道上游有什么，然后让下游干什么。然后才能业务逻辑完成。上下文有一部分是承接了接口规划的职责。但是上下文的定义在我们编程中还承担了另一部分职责，编码的可维护性。上下文设计的好，对于业务模块的拆解和组合复用很有帮助，对于多人协同开发同一业务模块也是可以提升单人开发效率的。上下文的规划，不只是包含了接口规划的部分，同时还包含了业务模块分层之后各分层之间上下文定义规划。

• 设计出承上启下所需要的完整的客观的信息内容，比如购买就涉及商品信息，价格信息，送货地址
• 上下文信息一定是因人的需要或者是用户需要绝对关注的，如果不符合，那就不符合，如果发现用户关注的信息不在定义里面，那么就是缺的

分层架构

        单个的微服务所采用的分层较多的是采用业务能力层(Feign),业务处理层(Service),数据结构层(DAO,Client)，然后有一些以DDD作为领域驱动设计的服务，还有领域层(Domain/Model)。大体上就这几类，一般有些事没有领域层的，可能就是吧领域相关的能力分散到业务处理层和能力层。如果要真的接近于显示逻辑编程还是需要领域层的。怎么划分根据命名就知道了，下面对这些各个层次的职责做简单说明。

• 业务能力层，提供给外部服务的能力，可包含有各个场景处理逻辑，参数预处理，与校验，调用业务层或者领域层，结果返回
• 领域层，每一个对象都是这个领域内某一对象所有的可能的业务处理操作，并调用业务逻辑处理
• 业务处理层，用来处理于业务相关的逻辑数据，基于数据结构的，不直接体现业务，只体现数据变更逻辑，增删改查等的处理，不应体现业务特点
• 数据结构层，这个是业务架构设计，以及业务分析，然后进行建模所产生出来的输出结果体系，他是底层数据呈现，是业务通达产品的媒介。

整洁架构-遵循设计原则

        整洁架构(Clean Architecture)，整洁代码(CleanCode)这都是现互联网时代所被倡导的，他只是为我们软件设计提供了一个目标或者比较理想的上实现。不管是整洁架构还是整洁代码都是整洁，都是对于用户或者使用方来说他的逻辑和实现都是符合简便的，简易的，完美的是实现了绝大多数人看待事物的逻辑。也就是接近于现实，现实事务在变化，代码和架构也能适应变化。而不管是代码整洁还是架构整洁，个人认为软件设计的六大原则是必不可少。

软件体系比喻：

        每个类就是一个工人，工人工作内容就是代码逻辑，能力就是类的方法，工人能力可以被赋予，教给其他工人，工人也需要协作，而统筹的管理人员本身也是一个工人，不过他的职责是协调其他工人

• 单一职责，每一个工人职责必须是单一的，这样工人自己认知才会明确，可维护
• 接口隔离，也可能有一类工人完成的事情一样，但是方法不一样，那么要归类的，这个就是就是定义接口，不能混淆
• 里氏替换，一个工人的职责是否可以被轻松替代，这个是来评判是否违背这个原则
• 开闭原则，这个时候需要认为这些工人没什么有学习能力，但是对于已经养成的习惯，他是很难改变，改变之后容易出错，所以就只能让他学习新的能力，不能修改旧的
• 依赖倒置，这个就是多个工人之间需要协调，相互协作，有些工人是被管理的，那么管理他的那个人就不可能再受制于他，不然命令下单就是乱的，场景不统一
• 迪米特法则，这个就是公司管理层或者工人之间的职责是各自独立的，如果有信息可以交流，那么信息就很容易泄露，就不安全了，工人之前相互了解越少越好

---

总结

综合以上，在使用应用中，还需要合理的进行复用，合理的规划类和实例对象。以完成好的代码架构。主要进行架构分层，业务分块，合理采用设计原则去设计对象，理解设计目的和设计思想。