上一篇文章《系统架构设计的原则》(没有阅读的同学可以点击进去提前了解下)出来后，有的同学说希望可以更详细的去了解下这几点原则，那接下来我就针对这几点原则，更为深入的讲述下在系统设计的过程中到底有哪些方面的点是需要关注的。
在我们开始做系统或者平台的技术架构之前，首先最为重要的，就是规定原则，根据原则，来框定我们系统设计的边界。原则如何来定呢？就需要提前对客户企业进行调研、分析，整理相关的调研报告、分析报告，把你和客户之间对即将要搭建的系统或者平台的认知拉到同一个水平。所以调研分析这一个步骤是必不可少的，调研的内容不仅仅是在IT信息层面，大方面的还有IT规划，企业发展的规划，业务发展的规划，业务发展的趋势，小方面的就有最终用户的分类特点，最终用户的操作习惯等等，缺乏实际的条件支撑，空谈系统架构，倒腾出来的东西就是垃圾。
从目前较为成熟的系统架构的发展情况来看，归纳总结起来不外乎是以下这个路线：
传统企业IT架构面临的挑战以及新架构发展趋势
整个发展路线来看，就是从单个系统，发展到以某个系统为中心的，再到基于某个平台进行构建的路线
系统化，中心化，平台化的发展
说到这里，就扯远一点吧。
如果大家听过中台并对中台有过一些了解的话，相信大家看到这里，对比一下，是不是就容易理解为平台化其实就是构建一个中台？中台的概念来源于阿里技术硬生生挤出来的一个形容自己政绩的词。它实际上要解决的根本的问题是组件重用的问题。在上一篇《系统架构设计的原则》中提到过，组件重用的问题其实在中心化的SOA架构中是重点去解决问题，但是SOA的中心化架构，带来的高耦合和高依赖性，使得运维成本极高。从而对SOA架构重用的组件更进一步抽象升级，到在一个整合的平台内，对更为基础的技术组件进行重用，而非是一些业务组件的重用。这样降低了依赖性的同时，也能保证系统的可重用性和可拓展性。所以在最开始的提出中台概念的时候，在IT架构领域，更多还是指技术中台，然后基于技术中台进行业务的拓展和实现，从而构成业务中台。通常理解业务中台是对内的，然后对外的是什么中台？有些IT服务商就提出了所谓的营销中台，采购中台，销售中台，制造中台等等各式各样的中台。
中台的价值
技术中台和业务中台都有的，对应的业务数据基础数据就产生的，业务梳理清楚了，接下来就是考虑数据的问题了，所以数据中台就出来了，考虑的问题是如何使企业的数据产生最大化的价值，所以涉及到一些列的数据分析，数据清洗，数据治理等等。
按照这样的发展，就出现了更为细分的领域，技术层面的就有了流程管理中台，消息中台，AI中台等等，以前在一个平台里面的某个组件，随着业务扩张，要么拓展成了多个服务，要么是被独立出来作为一个额外的系统，然后统称融合中台。按照这个发展趋势，那后面就朝着领域细分的角度，最后会不会有可能就变成了整个中台，就是由一个开发平台，加流程管理系统，消息管理系统，邮件管理系统，XXX技术类系统组成？？
技術中台的發展
是不是以上的这个图到最后就变得很熟悉的，像是又回归到了我们系统架构发展的开始的单体结构，然后把这些单体结构的系统圈起来，就构成了所谓的中台？
所以此处又有另外的一个观点，就是你是怎么看中台的呢？此处回归IT系统构建的本质，就是为了解决生产的问题，提高生产效率而去构建的一个工具，至于这个工具好不好用，最基本的评判标准，就是能否解决企业面临的相关问题。至于这个工具是用什么构造的，是什么样结构的，Who care ？
我们继续回到开始讨论的问题，系统架构的原则。
为了好看而毫无实际意义的图
本次细说下以下的这几点原则：系统安全性、系统性能、系统高可用、系统的可拓展性、系统可运营性，对于合规性和全球化的这两部分在中国境内目前暂时普及性还没那么高，接触也不是太多，特别是合规性部分，大多都要结合业务的实际情况去做相应的数据处理，所以就不在此班门弄斧了。
合规性要素探讨
系统设计的要素
系统架构的安全性
系统架构的安全性考虑
在网络安全层面，外网访问必走HTTPS，内网则普通的HTTP
身份安全层面，从安全审计、访问跟踪层面考虑，包括登录用户的角色权限，对数据的访问权限等一系列的权限控制；
在应用层面的安全性考虑，就有比较多：SQL 注入攻击预防，XSS 跨域脚本工具防御，多维度数据过滤，数据防篡改，数据脱敏，API网关认证，接口白名单
在数据库层面的安全性考虑，基本是这三点：启用多租户数据隔离，数据灾备，禁止直连数据库
以上是分层考虑的，再到整个系统或平台层面的一些安全措施，就有代码安全扫描，前端代码混淆处理，日志定时清理，日志脱敏，定期升级安全补丁，严格的用户管理以及密码策略，启用必要的系统安全日志和审计措施等，以及系统的安全监控如安全审计，链路跟踪，数据操作日志等；同时结合应用访问监控和预警，侦测是否有异常访问。
系统的高性能
系统的高性能分析
在前端，可以将静态资源通过CDN加速的方式，加速前端资源的加载；
服务端，通过服务集群部署，客户端与后台交互以及服务与服务间访问进行负载均衡，应用端进行读写分离的操作提升系统处理的性能
同时使用相对应的中间件如REDIS缓存，队列MQ等工具，使用缓存对数据进行冷热分离，通过MQ实现事件驱动模式支撑海量并发操作
在数据库层面，则是数据库读写分离，分库及分片处理提升读写效率
在整个系统层面，还需要考虑的一点是网络的因素，需要对网络进行优化，对业务量及用户群体分析确定服务的部署区域，尽可能避免跨区域数据传输
系统可用性
系统可用性说明
可用性主要在服务端体现以及对整个系统的监控、预警层面体现。
服务端的应对措施如下：
Ø微服务集群部署
Ø服务冗余部署策略
Ø服务限流
•服务熔断
•服务降级
•延迟处理
•特权处理
Ø服务无状态化
ØKeepalived服务监控
其他的像中间件，数据库，都主要体现在部署方式上，基本是搭建一个高可用的结构即可。从整个系统层面考虑的话，主要还是在系统监控层面：
硬件资源监控和预警(内存，CPU，硬盘)
软件使用情况监控(队列堵塞、数据库等待事件等)
在考虑系统高可用性的同时，往往伴随而来的我们也还需要考虑一个系统的事务一致性问题：
事务一致性考虑
系统可拓展性
可拓展性
通过现有的基础服务以及业务服务的组合，提升服务的可重用性
服务的集群部署，可以动态的增加或减少服务实例的数量，从而实现系统的横向拓展
系统的可运营
可运营性体现就比较多比较细，但主要的一个原则是，尽可能的降低后期运维的技术人员的工作量，以及提升关键用户对系统出现的问题的处理能力。对于如何降低运维人员的工作量，主要一个点在于，系统出现问题时，最终用户或者关键用户可以根据问题的描述，或者相关提示，相关日志，即可自行解决问题，使得问题不需要流转到最终的运维技术人员。同时出现了问题时，有相关的预警，发送到相关人员，督促相关人员作出相关决策或者措施；从技术角度看，在发现BUG漏洞时，不需要通过翻查源码，场景重现即可找到出现BUG的地方，而是通过日志跟踪的手段，来发现问题的原因。
这些都是系统可运营性的关键要素哦。
以上仅为个人观点，仅供参考。如有侵权，请联系。
